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Preface 



This volume is a documentation of the main results in the research area “Inte- 
gration of Software Specification Techniques for Applications in Engineering”. 
On one hand it is based on the Priority Program “Integration von Techniken der 
Softwarespezihkation fiir ingenieurwissenschaftliclie Anwendungen” , short Soft- 
Spez, of the German Research Council (DFG) . On the other hand it contains new 
contributions of international experts in this research area, some of which were 
presented at the third international workshop INT 2004 on “Integration of Spec- 
ification Techniques for Applications in Engineering”. INT 2004 was launched 
as a satellite event of ETAPS in Barcelona, the “European Joint Conferences on 
Theory and Practice of Software” . 

The Priority Program SoftSpez was initiated by W. Brauer, M. Broy, 
H. Ehrig, H.J. Kreowski, H. Reichel, and H. Weber concerning different aspects 
from computer science, and by E. Schnieder and E. Westkamper concerning 
two main application areas in engineering, namely “Traffic Control Systems” 
and “Production Automation”. After acceptance of SoftSpez by the German 
Research Council for the period of 1998-2004 a call for specific projects within 
this priority program was launched, where 11 projects from about 75 project 
proposals were accepted for a period of two years. Since 1998 each year the 
main research proposals and results of the projects have been presented at an 
annual colloquium of the priority program, and every two years the projects 
have been evaluated by an independent group of referees appointed by the Ger- 
man Research Council. At this point we would like to thank A. Engelke and 
G. Sonntag, the responsible officers from the DFG, the group of referees, with 
chairman W. Brauer, and our colleagues mentioned above for setting up the 
initial proposal for SoftSpez. 

The cooperation between the projects was organized into different subject 
areas, with several meetings since 1999. In addition to the annual colloquia and 
the subject area meetings on a national level, also three international workshops 
were organized by SoftSpez. The workshops INT 2000, 2002, and 2004 were 
launched in cooperation with the ETAPS conferences in order to present the 
concepts and results of SoftSpez to the international scientific community and 
to get feedback from international experts. 

The contributions in this volume are organized according to the six different 
subject areas of SoftSpez, where the coordinators for the subject areas are the 
coeditors for the corresponding parts of this volume. All papers were carefully 
reviewed by national and international experts. 

In addition to a general introduction to the research area of this volume 
there are also introductions for each subject area. They present an overview and 
a short introduction into each paper of the corresponding subject area, including 
contributions from the projects of SoftSpez and papers from international (non- 
German) experts in this area. 
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Preface 



The organization of the priority program SoftSpez and of the six subject 
areas was coordinated during the program and for this documentation by 
the editor and the coeditors of this volume, respectively. For great support 
we would like to thank the following researchers of the project: M. Bengel, 
A. Braatz, B. Braatz, R. Geisler, H.M. Hanisch, L. Jansen, G. Julias, M. Klar, 
M. Klein, J. Klose, R. Lorenz, G. Saake, Cli. Schaeffer, G. Schellhorn, G. Schroter, 
R. Slovak, A. Thums, and B. Westphal. 

Finally let us thank all national and international reviewers and authors of 
the papers in this volume and Springer for a smooth publication. 

We hope that this volume offers new insights and suggests new research topics 
and applications in various related areas of computer science and engineering. 



July 2004 Hartmut Elirig 

Werner Damm 
Jorg Desel 
Martin Grofie-Rhode 
Wolfgang Reif 
Eckeliard Schnieder 
Engelbert Westkamper 
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Integration of Software Specification Techniques 
for Applications in Engineering: 
Introduction and Overview of Results 



Hartmut Ehrig 

Institute for Software Engineering and Theoretical Computer Science 
Technical University of Berlin, Germany 

ehr ig@cs . tu-berlin . de 



Abstract. This contribution is a short introduction into the research 
area, which was subject of the priority program SoftSpez of the German 
Research Council (DFG) in the years 1998-2004. Starting with the aims 
of this priority program, we give an overview of the activities of SoftSpez 
and the related international workshops INT 2000-2004 and of the results 
in six different subject areas presented in this volume. 



1 Aims of the Research Area 

The research area “Integration of Software Specification Techniques for Applica- 
tions in Engineering” has been established as a priority program of the German 
Research Council (DFG) for the period of 1998-2004 and was subject of the 
international workshops INT 2000, 2002, and 2004 as satellite events of the “Eu- 
ropean Joint Conferences on Theory and Practice of Software” (ETAPS). The 
aim of the priority program SoftSpez was to establish the integration of different 
specification and modeling techniques for the development of reliable safety and 
security related software systems for applications in engineering, especially in the 
areas of production automation and traffic control systems. The results of this 
research should lead to a theoretically well founded integration of mathematical 
and pragmatic techniques and tools for software specifications in different ap- 
plication areas. The research proposal of SoftSpez includes mainly the following 
four areas, which are presented in [1] in more detail. 



1.1 Integration of Software Specification Techniques 

In the 90s there has been already a large variety of software specification tech- 
niques which are suitable for specific aspects in the software development process. 
In most applications, however, it is not sufficient to use only one technique, but 
various techniques have to be used for different purposes. For data type aspects 
there are date type specification techniques, like algebraic specification, Z and 
B, while process techniques, like process algebras, Petri nets and statecharts, are 
used for dynamic aspects of systems. All these are formal specification techniques 
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with a well-defined mathematical syntax and semantics. For object oriented soft- 
ware development the Unified Modeling Language UML provides a large variety 
of different diagram techniques for different purposes. 

Most of the UML techniques are semiformal in the sense that there is a 
well-defined syntax, but in most cases there is only a textual description of the 
intended semantics. This leads to several integration tasks: 

1. Integration of different formal techniques in order to have a united technique 
for different aspects, like data types and processes, including well-defined 
semantical foundations and verification techniques. 

2. Integration of semiformal and formal techniques in order to apply formal 
semantics and verification techniques also to semiformal techniques. 

3. Integration of methods and tools for different specification techniques in 
order to provide a suitable software development environment. 

1.2 Integration of Techniques and Methodologies in Computer 
Science and Engineering 

Based on techniques and methodologies in engineering on one hand and results 
concerning the integration of software specification techniques in computer sci- 
ence on the other hand it is necessary to integrate these techniques including 
the following tasks: 

1. Compatibility of the specification for functions performed by physical com- 
ponents in engineering, especially sensor-actuator and other physical devices 
of embedded systems, with those of software components including real-time 
aspects. 

2. Integration of established graphical means of description and visual modeling 
techniques which have been developed separately in both areas in order to 
support the intuitive understanding of physical systems as well as software 
systems. 

3. Integration of views, aspects and related models in both areas in order to 
bridge the gap between different methodologies in computer science and 
engineering leading to reliable embedded systems in the application areas. 



1.3 Meta Models for Integration 

In areas 1.1. and 1.2 above it is intended to integrate specific specification tech- 
niques from computer science and engineering. It remains to study the general 
principles how to integrate specification techniques not only on the syntacti- 
cal, but also on the semantical and the methodological level. The meta model 
for UML, which includes meta models for all the different UML diagrams, is a 
typical example for the syntactical integration of different modeling techniques. 
This concept, which can certainly be applied also to other visual modeling tech- 
niques, can be considered as a meta model for syntactical integration. In order to 
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support correctness and verification of systems, however, it is even more impor- 
tant to develop a meta model for semantical integration which can be applied 
to different concrete specification techniques, especially to the UML diagram 
techniques. 



1.4 Reference Case Studies in Production Automation and Traffic 
Control Systems 

In order to support the cooperation between computer science and engineering 
one of the main aims of the priority program SoftSpez is not only the integration 
of software specification techniques but also the applications of these techniques 
to realistic problems in engineering. 

For this purpose two experts from engineering, E. Westkamper and 
E. Schnieder, have been asked to join the group of initiators from computer 
science and to provide realistic reference case studies from different application 
areas in engineering: 

1. The aim of the Reference Case Study Production Automation is to give a 
practical insight into future requirements of software specification on the ex- 
ample of material flow. The specific challenge is to develop agent-based soft- 
ware structures which help to increase the reliability of production systems 
via mechanisms of self-configuration, self-analysis and self-optimization. 

2. In the area of Traffic Control Systems a typical example for a safety related 
case study is the level crossing with barriers. This second reference case study 
was developed with support of the Deutsche Balm AG. Its challenges are 
radio based communication and dual hybrid dynamics with discrete events 
and continuous behavior. 

2 Organization of the Priority Program SoftSpez 

After acceptance of the priority program SoftSpez by the German Research 
Council (DFG) in 1997 a call for specific projects within this program was 
launched, where especially the cooperation between computer scientists and en- 
gineers within one project was required. From about 75 project proposals 11 
projects were selected by an independent group of referees appointed by the 
DFG. In the first colloquium of the priority program end of 1998 it was decided 
to organize the work in seven different subject areas, where later two of these 
areas were joined leading to the following six areas: 

1. Reference Case Study Production Automation 
(Coordinator: Engelbert Westkamper) 

2. Reference Case Study Traffic Control Systems 
(Coordinator: Eckelrard Schnieder) 

3. Petri Nets and Related Approaches in Engineering (Coordinator: Jorg Desel) 

4. Charts (Coordinator: Werner Damm) 
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5. Verification (Coordinator: Wolfgang Reif) 

6. Integration Modeling (Coordinator: Martin GroBe-Rhode) . 

The subject areas 1 and 2 are the two parts of research area 4 (Reference 
Case Studies in Production Automation and Traffic Control Systems), subject 
area 6 corresponds to research area 3 (Meta Models for Integration), and the 
subject areas 3, 4 and 5 cover main parts of research areas 1 and 2 (Integra- 
tion of Software Specification Techniques resp. Techniques and Methodologies 
in Computer Science and Engineering). Although there is in principle a large 
variety of specification techniques suitable for the SoftSpez proposal, it turned 
out that in the accepted projects different kinds of charts, closely related to 
corresponding UML techniques, as well as Petri nets and related approaches 
in engineering were dominant and that also verification techniques should be 
grouped together in a separate subject area. Altogether it turned out that each 
of the 11 accepted projects are strongly related to two or three subject areas, 
especially because each project was required to provide a solution to one of the 
reference case studies or closely related industrial problems. 

Each of the six subject areas has organized a corresponding annual workshop, 
where not only the problems but also the solutions of the different projects for 
this subject area were discussed. The main results were presented on the annual 
symposium of SoftSpez. 

In order to discuss the topics and results of SoftSpez also within the inter- 
national community a first international workshop on “Integration of Software 
Specification Techniques with Applications in Engineering”, short INT 2000, was 
organized as satellite events of the prestigious international ETPAS 2000 confer- 
ence in Berlin. The forum of ETAPS (European Joint Conferences on Theory and 
Practice of Software) has allowed starting a discussion of the SoftSpez research 
area with leading international experts. Due to its success the INT workshop 
was repeated twice with INT 2002 and INT 2004 as satellite event of ETAPS 
2002 in Grenoble and ETAPS 2004 in Barcelona. In each of these INT workshops 
the SoftSpez coordinator gave a short overview of the ongoing priority program 
in Germany, and for each of the subject areas one main contribution from one 
of the projects and also from an invited international speaker were presented. 
The workshops were organized by key members of SoftSpez in cooperation with 
international experts in the field. Some of these international speakers have been 
invited again for a contribution in this volume. 



3 Overview of Results 

In this section we give a short overview with selected, typical examples how the 
aims of the research areas 1.1-1. 4 presented in section 1 have been realized within 
the priority program SoftSpez in the subject areas 1-6. For a mid-term report 
we refer to [2] and for more details to the introductions of the corresponding 
subject areas and to the papers in this volume. 
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3.1 Results in Research Area 1.1 

The integration of software specification techniques was mainly studied in the 
subject areas 4 and 5 with focus on different kinds of charts and verification tech- 
niques. For the subject area “charts” main contributions have been provided by 
the projects USE, FORMOSA and SFC-Clreck and D. Harel as international 
expert. Charts comprise statecharts in the UML semantics and also the classi- 
cal statemate semantics, Sequential Function Charts (SFC) and Live Sequence 
Charts (LSC). A prime topic of this subject area was the definition of a rigorous 
semantics of the considered charts languages, which is a prerequisite for formal 
correctness and verification. The important role of LSCs was pointed out by 
D. Harel in his invited lecture at INT 2004, concerning his novel approach to 
programming of reactive systems. In this approach - presented in his book [3] - 
inter-object scenario-based behavioral requirements are “played in” directly from 
the systems GUI (graphical user interface), and behavior can then be “played 
out” freely adhering to all the requirements. The language he used is an enriched 
version of the LSCs, that were originally developed by him and W. Damm [4]. A 
complete formal semantics of LSCs is one of the main aims of the project USE 
presented in this volume [5]. 

Verification - considered by the projects FORMOSA, ISILEIT, USE, SFC- 
Check and GRASP in subject area 5 - allows proving rigorously that a certain 
property holds for a formal system model. As discussed in the introduction to 
this subject area the verification task can be split into three parts. The first 
step is to build a formal model of the system using suitable specification tech- 
niques, e.g. those considered in subject area 4 or those presented by D. Bjprner as 
international expert in [6] . The second step is to identify important safety prop- 
erties, where safety analysis techniques like FTA and FMEA from engineering 
can help to find them. Combining these safety analysis techniques with formal 
specification and verification techniques is the aim of the FORMOSA project 
presented in this volume [7], which has been applied to an important industrial 
case study, the “height control in the Elbtunnel” (see [8]). The third step is then 
the verification for the properties for a given system using well-known interactive 
verification or model checking techniques and tools. 



3.2 Results in Research Area 1.2 

The integration of techniques and methodologies in computer science and engi- 
neering was mainly studied in the subject areas 1-3, where areas 1-2 will be dis- 
cussed in 3.4. The main aim of subject area 3 (Petri Nets and Related Approaches 
in Engineering) is to study the relationship of process specification methods 
and languages in the areas of computer science and engineering (see [9]). The 
contributions in this volume have been provided by the projects SPECIMEN, 
GRASP, KNOSSOS and DISPA, and the international experts L.M. Kristensen 
and K. Jensen. One typical example for this subject area is the well-known spec- 
ification language MFERT for production automation systems studied in the 
GRASP project (see [10]). MFERT-models have many similarities with Petri 
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nets, but MFERT has no formal semantics as basis for verification. For this 
reason MFERT models are translated to I/O Interval Structures, which allows 
using the model checker RAVEN to check real-time properties of the MFERT 
model. These properties are specified in RT-OCL, a real-time extension of the 
language OCL for the specification of constraints in UML. Among other exam- 
ples is the synthesis of control in automation systems in the project SPECIMEN 
using signal nets, an extension of Petri nets by signal arcs (see [11]). 

3.3 Results in Research Area 1.3 

General concepts of integration, which can be applied to different specific spec- 
ification techniques, have been studied in subject area 6 (Integration Model- 
ing). According to [12] integration modeling includes methodological, ontological 
and formal semantics integration. One of the main results is the language- and 
method-independent model integration of the project IOSIP presented in the 
EATCS Monographs in TCS [13]. This semantical framework for model integra- 
tion is based on a uniform concept of transformation systems, which allows the 
semantic integration of heterogeneous software specifications. The integration 
model has been adapted to object-oriented systems in [14], which allows study- 
ing semantical integration of object-oriented viewpoint specification techniques 
as considered in UML. The approach presented by the international expert F. 
Orejas [15] addresses the orthogonal issue of the integration of specification mod- 
ules that are presented in different notations based on the categorical framework 
of institutions. 

3.4 Results in Research Area 1.4 

In the subject areas 1 and 2 different solutions have been presented for the 
reference case studies in production automation and traffic control systems re- 
spectively. 

For the case study in production automation and a closely related flexible 
production system solutions are presented in this volume by the projects IOSIP, 
DISPA and ISILEIT based on UML, UML-PA and UML and SDL respectively 
(see [16]). UML-PA is a process automation extension of UML developed within 
the project DISPA. In cooperation between the GRASP and the IOSIP project 
a simulation tool has been developed, which allows illustrating the reference 
case study production automation. An important achievement for the applica- 
tion area of production automation is the development of the object-oriented 
specification method ODEMA (Object-oriented Method for Developing Techni- 
cal Multi- Agent-System) based on UML (see [17]), which has been developed in 
the project IOSIP and applied to the reference case study. 

The reference case study Traffic Control Systems was especially considered 
by the projects KNOSSOS, SafeRail, and HYBRIS, which are discussed by 
E. Schnieder in [18] in more detail. In order to demonstrate the corresponding 
specifications a scaled model of a level crossing and a train model were con- 
ceived, constructed and validated using simulations. This test environment was 
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frequently used by the projects within this subject area. The results have been 
presented on an international level not only on the INT-workslrops mentioned 
above, but also on the international conferences FORMS 1998-2000 and FORMS 
2003 (Formal Methods for Railway Operation and Control Systems, see [19]). 

3.5 Conclusion 

As sketched above and shown in more detail in this volume the main aims of the 
research area Integration of Software Specification Techniques for Applications in 
Engineering have been achieved by the projects of the priority program SoftSpez. 
The corresponding results have been presented not only on national, but also 
on several international conferences and workshops. The feedback with interna- 
tional experts, especially with those presented in this volume, was important for 
a smooth development of the research area on a high international level. More- 
over the cooperation between scientists from computer science and engineering 
was important to achieve results which are relevant for both communities. The 
techniques presented in this volume have been applied successfully not only to 
the reference case studies in production automation and traffic control systems, 
but also to several industrial projects. 
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1 Introduction 

The applicability of the integrated techniques and methods, which are developed 
within the DFG priority program Software Specifications, is shown by means of 
two reference case studies, that describe typical systems from engineering point 
of view. One belongs to the area Production Automation. The characteristic 
aspects of process automation and the realized systems are focused in the case 
study, including open and closed loop control, real-time aspects as well as dis- 
tribution of control functions. 

As an introduction, the requirements of process automation and the case 
study Production Automation itself are discussed. This is followed by three pa- 
pers, which are developed from project partners in the DFG priority program 
Software Specifications [1], The fourth paper is a look into the future. It handles 
the future requirements in software specification for manufacturing systems [2]. 



2 General Characteristic Aspects of Production 
Automation 

Concerning the requirements of process automation the case study Production 
Automation was chosen. The requirements of Production Automation can be 
structured regarding different aspects like open and closed loop control, real- 
time and distribution. In the following, some of these aspects are described. 

Mostly, the technical process requires a temporally defined and cyclic ma- 
chining. So it requires a deterministic behavior regarding real-time aspects of 
the control algorithms. Processes and their controlling algorithms respond sen- 
sitively to jitter in cycle times. 

For processing of execution controls, the monitoring of limit values and of 
asynchronous events’ return values is extremely important. Some tasks have to 
be executed at absolute times. These requirements cause complying with the 
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real-time behaviour. The term real-time behavior includes requirements for si- 
multaneity and timeliness within quasi parallel program execution. DIN 44300 
[3] defines real-time as the deterministic behavior of a control system to be avail- 
able for unexpected events within a given period of time. This functionality is 
supposed to be a standard for each real-time operating system. In practice, there 
is a differentiation between hard and soft real-time. Hard real-time considers the 
exceeding of a given period of time as a total failure of the whole system. Soft 
real-time still accepts this exceeding if the resulting damage is not too bad. 
DIN 44300 reduces real-time capability to maximal reaction times, i. e. bounded 
responses. 

Manufacturing systems are often distributed systems with different targets 
connected via field bus. The sum of distribution aspects is listed in table 1. This 
table shows the first level of a morplrologocal box for distributed systems. This 
morphological box [4] was developed on the basis of properties in automation 
literature [5, 6, 7] and heuristics. This box is an appliance for the morphological 
method, whereas a problem is split multidimensionally into single parts. 

In the Reference Case Study Production Automation a special form of dis- 
tributed systems is utilized. The so-called agents are explained in the following. 

In general, an agent is someone acting on the order of someone else. A techni- 
cal agent in the Production Automation can be described as follows. Regarding 
technical systems, agents are understood as autonomous, cooperating entities in 
distributed, decentral systems [9]. Basically, technical agents are to be distin- 
guished from software agents. In contrast to technical agents, software agents 
are software entities. Based on the definition of Liith, a technical agent can be 
seen as an autonomous, interactive entity with its goal to optimize and stabi- 
lize a process. Further on, the technical agent is equipped with intelligence, i. 
e. mainly the capability to learn, and the capabilities to cooperate and coordi- 
nate [10]. Autonomy is the agent’s capability to take decisions on its own and 
to create plans depending on its role [11]. The agentification is the process of 
identification and modeling of technical processes and systems. 

3 Characteristics of the Reference Case Study Production 
Automation 

3.1 Introduction 

The aim of the Reference Case Study Production Automation is to give a prac- 
tical insight into future requirements of software specification on the example of 
material flow. Agent-based software structures will help to increase the reliabil- 
ity of production systems via mechanisms of self-configuration, self-analysis and 
self-optimization. 

As physical manufacturing environment for the Reference Case Study a 
rather simple production system has been selected on the basis of a shop floor 
system for deburring of metal parts. Typical metal parts for deburring in this 
shop floor are: motor blocks, crank shafts, exhaust pipes etc. The shop floor 
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Table 1. Sum of distribution requirements. 



Distribution aspect 


Specificity 


Description 


Autonomy / self-government 


— Independent / non- 
cooperating 

— Dependent- 
cooperating 

— Stand-alone function- 
ing 

— Interacting 


Dimension for indepen- 
dence of certain functions 
from regular influences. 


Heterogeneity 


— Homogeneous 

— Heterogeneous 


Configuration description 
of several - maybe different 
hardware and software 
modules. 


Transparency 


— Access 

— Concurrency 

— Parallelism 

— Degree 

— Failure 

— Location 

— Migration 

— Persistence 

— Relocation 

— Replication 

— Fragmentation 

— Name 

— Scalability 


Hiding of distribution from 
users and applications. 
With a certain degree of 
transparency the impres- 
sion of a single processor 
system could be given. 


Modularity 


— Openness 

— Flexibility 

— Scalability 


The term modularity con- 
sists of these three items. If 
a system is open, then it is 
flexible and scalable as well. 


Dependability 


— Reliability 

• Availability 

• Certainty 

* Safety 

* Security 

— Fault tolerance 

— Fault processing 


These items are well dis- 
cussed in conventional liter- 
ature [5, 6, 7, 8]. 


Synchronization 


— Asynchronous process 

— Synchronous process 


Synchronization regarding 
the real-time ability of con- 
sidered systems. 


Performance 


— User aspects 

— System aspects 

— Cost aspects 


The performance regarding 
information technology. 
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consists of three different machining centers: a five-axes milling machine and 
a three-axes milling machine (machine tools), both for deburring, and a final 
washing machine. Input of parts in terms of material flow is an automatic shelf 
storage in which all parts that are waiting for deburring are stored. Output of all 
parts, after the process of deburring and washing is completed, is a second auto- 
matic shelf storage waiting for all finished parts to come in for further delivery 
to the next shop floor area. 

The material flow system - while deciding on all transport tasks and assign- 
ing them - is fully responsible for the resulting throughput and production rates 
on the shop floor. In this case study three free-ranging Automatic Guided Ve- 
hicles (AGV) are in charge of performing all transport tasks. But in contrast to 
traditional AGV systems, in this case there is no central disposition dispatcher in- 
volved, assigning given tasks to AGVs. Therefore the three AGVs act completely 
on their own, independent of any central supervisor. They are autonomous, self- 
responsible, cooperative agents, that behave like little taxi drivers in a modern 
city, assigning themselves to individual transport tasks that are offered by a 
broadcasting system. Such an agent-oriented behavior in manufacturing is lead- 
ing to a Holonic Manufacturing System (HMS) with lrolonic AGVs (H-AGVs) 
[12] which is considered as a special case of technical agents. 

Taking into account the features explained in table 1, table 2 can be derived. 



Table 2. Distribution aspects applied to the Reference Case Study Production Au- 
tomation. 



Distribution aspect 


AGV 


Machine tool 


Autonomy 


Dependent-cooperating 


Stand-alone functioning 


Heterogeneity 


Homogeneous 


Heterogeneous 


Dependability 


Only applicable in the ex- 
tended version 


Only applicable in the ex- 
tended version 


Synchronization 


Asynchronous 


Synchronous 


Performance 


System and cost aspects 


System aspects 



In figure 1 the Reference Case Study is modeled in a simulation program pro- 
vided by the project GRASP [13]. On the right is a hall housing the AGVs when 
they are not used. On the lower side there are the two automatic shelf storages 
for input and output. On the left and on the top the two milling machines are 
located, and on the top right, there is the washing machine. Finally, on the free 
area in the middle, the three AGVs are handling transport tasks. 

A specification of the Reference Case Study Production Automation was 
already prepared using the ODEMA method (Object-oriented Method for De- 
veloping Technical Multi- Agent-Systems) [14, 15]. 

The aim of this case study is to maximize performance of work pieces without 
losing the easy configurability. Therefore, the control systems for the AGVs, the 
machine tools and the storages have to be specified. 
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Fig. 1. Reference Case Study modeled in the GRASP simulation tool. 



Extension of the Reference Case Study: The Reference Case Study con- 
sists of a basic version and an extended version. Basically, the extended version 
demands a more realistic model of the real world. In more detail, the resources 
have to be handled as well as malfunctions and failures. Another important detail 
is that there are less restrictions to the numbers of available subsystems. 

All the differences between these two versions are shown in table 3. 



3.2 Control Systems 

Generally, the system decomposition of automation systems and their control 
systems respectively may be described by a model consisting of five levels which 
are characterized by their functions regarding the application processes [16, 17, 
8, 18, 19]. This model is also known as the CIM pyramid (Computer Integrated 
Manufacturing). The lower three levels are depicted in figure 2. 

In the factory management level, the Enterprise Resource Planning Systems 
(ERP) are located to handle the whole factory’s logistics, e. g. gathering orders. 
In the second level, the production management level, Manufacturung Execution 
Systems (MES) are responsible for one production site, they create production 
orders etc. The process management level synchronizes various machines and 
offers user interaction, whereas the process control level consists of different 
functions with various time constraints: 
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Table 3. Differences between the basic version and the extended version of the Refer- 
ence Case Study. 



Property 


Basic version 


Extended version 


Power supply 


Power capacity is sufficient: 
no charging is necessary. 


Charging station is re- 
quired. 


Machine tools’ malfunctions 


No malfunctions in machine 
tools. 


Mechanical failures are pos- 
sible. 


Communication 


Loss-free communication. 


Disturbances are possible. 


Collisions of AG Vs 


No collisions are possible 
because of defined routes. 


Extension of layout leads 
to reserving routes to avoid 
collisions. This is supposed 
to be implemented by a 
Routes’ Management Sys- 
tem. 


Deadlocks 


Not possible because of 
collision- freedom. 


Have to be avoided. 


Number of AG Vs 


Limited to three AGVs. 


Number of AGVs can 
change dynamically. 


AGV’s waiting position 


Not applicable. 


After having finished a 
transportation task, the 
AGV moves to a defined 
waiting position. 



1. Axis Control 

Usually a closed loop system to control the axes’ positions that is quasi- 
continuous. 

2. Motion Control 

Mostly a closed loop system to handle the movements of axes, actuators and 
so on. This is as well quasi-continuous. 

3. Logic Control 

A state-based discrete control of behavior. 

4. Process Control 

Control of additional functions. 

5. Man-Machine Control 

Event-discrete as a part of the Logic Control. 

Finally, the Process Level houses sensors and actuators to establish the connec- 
tion to the physical process. 

This layer model acts on the assumption of a hierarchical approach, i. e. the 
higher levels use services and data from the lower ones. Therefore, the functions 
of application processes need certain properties offered by the hardware com- 
ponents. This means that by this layer model types of automation devices are 
defined as well. Components located near the process itself possess a real-time 
operating system leading to a deterministic behavior of application processes. 
Simple field devices (sensors, actuators) do not make use of control functions, 
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Fig. 2. Factory Layer Model. 



but in fact they are the interface to the technical process. So-called intelligent 
field devices are components that link sensors or actuators to control functions. 

As a matter of principle, control systems are seen as distributed systems. 
This means that the devices are linked by various communication systems, of 
which the properties are defined as well by the layer model. Typically, there is 
a difference between the field bus to transmit small amounts of data in hard 
real-time (cf. next section) and the factory bus to transmit larger data without 
any temporal restriction. 

In the layer model above at least the lower two levels are distributed. The 
communication objects involved are mainly events, real-time process data, syn- 
chronization signals, alarm signals, status, and configuration values. 



Configuration: Each system, i. e. machine tools, AGVs and shelf storages, 
has its own control system which is to be specified. Furthermore, there is a 
system technology consisting of sensors for navigation, obstacle avoidance etc. 
and actuators for driving, steering, and work piece handling. 

The system technology is encapsulated and transparent with regard to the 
needs of designing the control systems. It can be considered as a black box, i. e. 
the layers of process control and process in the factory layer model (cf. figure 2) 
are not demanded by the Reference Case Study. 

All the manufacturing system’s subsystems synchronize themselves via a 
radio-based broadcast communication system. It ensures that every message is 
delivered to each connected system. The development of an architecture based 
on a broadcasting communication model is shown in [20] . 

It has to be pointed out that the AGVs’ controls are the only ones being 
holonic, i. e. autonomous. The other ones’ actions are dependent on the current 
system status. 
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To keep the system’s configurability easy the machine tools do not know 
anything about the process of manufacturing. They are limited to transmitting 
(broadcasting) their status and to execute their manufacturing steps. 

The AGVs receive the machines’ states. Additionally, they know about the 
process of manufacturing as they know the direction and order of material flow 
inside the manufacturing system referring to a certain work piece. Based on 
this information, the AGVs are able to start negotiating about getting transfer 
orders. 

A module’s behavior (i. e. of a machine tool or an AGV) is described by 
message sequence charts or state charts. As an AGV is considered as a transport 
agent (cf. Agent-oriented Open Loop Control), the agent’s head is responsible for 
the behavior and communication. The agent’s body with the axis controllers for 
example are left out here. This correlates to the process control and the process 
itself in the factory layer model, as explained above. 



Decentralization: The AGVs’ control systems are lrolonic. A holon is a mixture 
of autonomy and ability of cooperation, i. e. it is ambitious to keep its autonomy 
as well as integrate itself into holarchies. In this context, a lrolarchie is a dynamic 
hierarchy of lrolons [21]. As holonic architectures cannot be implemented by 
conventional methods, other concepts have to be used. The concept of intelligent 
agents is suitable for holonic systems as there is as well a decentralized way of 
problem solving by autonomous and cooperative entities. If within one system 
multiple agents interact or cooperate, it is called a Multi- Agent-System (MAS). 



Agent- Oriented Open Loop Control: The AGVs are identified as tech- 
nical agents to form a transport MAS [22]. Braatz developed the UML-based 
method ODEMA (Object-oriented Method for Developing Technical Multi- 
Agent-Systems) to design technical agents [14, 15]. 

Conventional structuring methods for manufacturing are following two 
philosophies: 

— Material flow: control is mainly determined by the transport system. 

— Work flow: control is mainly determined by the manufacturing processes. 

In conventional systems, the control hierarchy does not allow to optimize and 
adapt the ratio of material flow and work flow. Agent control fills in this gap. 

The AGVs are the only agentified parts in the whole manufacturing system. 

If a machine tool transmits its status, the AGVs extract a transfer order out 
of it if there is a workpiece to be moved. The first AGV to recognize the transfer 
order becomes a moderator and broadcasts a call for bids. The other AGVs 
receive this call and calculate their costs to move this workpiece, based on their 
distance to the workpiece and the difficulty to reach it. If its own bid is better 
than the other ones, it takes part in the bidding. After a certain amount of time 
the moderator finishes the bidding and accepts the best one. This procedure 
maximizes the system’s load at the lowest costs. 
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Holonic Material Flow: In contrast to hierarchical systems, lrolonic systems 
are able to combine hierarchical and heterarchical properties. If a module of 
the whole system changes or fails, this can be compensated by adaptation of 
the whole system. Moreover, fixed hierarchies are said to doom in nature while 
dynamic holarchies assure stability and growth [23, 24]. 

Holonic manufacturing systems (HMS) are based on the approach that lrolons 
(agents) cooperate and act to increase common welfare (cf. Decentralization). 
The main goal of holonic manufacturing systems is that each holonic AGV (H- 
AGV) acts autonomously and cooperatively on its own. There is no central 
disposition system needed for job assignment. This goal is reached by several 
properties: 

— Autonomy and self-organization 

Transport tasks are only negotiated if the H-AGV is not currently allocated 
by another task. The H-AGV plans its way to the goal individually and it 
takes care of the battery load status, i. e. the resource management, on its 
own. 

— Cooperativeness 

Transport tasks are only negotiated if no other lrolon can perform it better. 
The H-AGV publishes all information on its status and decisions to others. 

— Self-optimization 

The H-AGV takes the best way to the target, depending on the traffic situ- 
ation. For reducing waste of energy, it tries to avoid traveling without load. 
In case of road obstacles it surrounds them or replans its way. To maximize 
the system performance, the most important task is handled first. 

— Intelligence 

Transport tasks are only negotiated if they can be executed. The H-AGV 
checks for and avoids dead-lock situations on shop floor level. 

— Forecasting 

If no transport tasks are active or pending, the H-AGV forecasts new tasks 
and already goes there. 

— Considerateness 

If no transport tasks are active or pending, the H-AGV does not disturb the 
others. 

It has to be mentioned that some of these items like intelligence, forecasting 
and considerateness are not required in any version of the Reference Case Study. 
The extended version demands for self-optimization in addition, which is not 
part of the basic version. 



Components and Interfaces: The agent- and object-oriented specification 
method ODEMA was applied to this case study. By using system and software 
decomposition the system to be specified is described by UML function blocks, 
components and later on by classes and interfaces [25] . 
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4 Application of the Reference Case Study Production 
Automation 

In the topic area Reference Case Study Production Automation there are various 
projects dealing with this case study. A short overview about the results is 
following. 

4.1 IOSIP 

The function block-model as a notation is the most common approach for de- 
scribing control applications in automation systems. For establishing UML-based 
methods in this area, it is required to map this domain-specific notation to de- 
sign techniques of UML. Bearing in mind that the model of function blocks is 
established as a descriptive notation for distributed control systems in automa- 
tion systems, the mapping to the UML harnessed a well-known tool in the world 
of software development to the engineering in automation. Further on, an ap- 
proach is given to change methodically from system and control development to 
software development, like it is required in the ODEMA method’s conception 
[14, 15]. 

Motivated by the wide acceptance of component-based technologies in soft- 
ware development it is shown by example, how to apply component concepts for 
software engineering to modeling in the field of production automation. The ex- 
ample of the modeling of a holonic transport system shows how function blocks 
in the sense of production automation can be understood as software engineering 
components. Thus, the advantages of component-based modeling with respect 
to structuring, exchange and reuse can be transferred to systems in production 
automation [25]. 

As a third part the semantical consistency of viewpoint-oriented modeling 
techniques in production automation is considered. The role of the viewpoint 
concept, known from software engineering, is of increasing importance for mod- 
eling in production automation. While most often only a syntactical consistency 
check is performed for viewpoint oriented modeling techniques, this work exam- 
ines semantical consistency. Semantical modeling and model-based consistency 
checks are presented along an example of a machining tool robot [25] . 



4.2 DisPA 

In the project DisPA a draft for an object oriented approach for the domain of 
automation and process control engineering is derived. This approach includes 
UML stereotypes for control (closed and open loop) and uses configuration of 
attributes and operations to achieve reusability of modules. Besides, constraints 
for real time applications are necessary. This developed UML subset is called 
UML-PA (PA - Process Automation) [26] . 

The case study Production Automation has been selected to serve as evalua- 
tion environment for the embedded software to be designed with UML-PA. The 
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Fig. 3. Part of a continuous hydraulic press in Timber Industry with Block Diagram 
(block diagram for frame i, i= 1- 80, L - left system). 



practicability of UML-PA as well as the code size and the required computational 
performance of the software will be evaluated. Therefore, the extended part of 
the Reference Case Study Production Automation is realized at the University 
of Wuppertal, LFA [27]. 

The demonstrator is built of several single board computers (SBC) with a 
real-time operating system (RTOS-UH) connected via CAN bus. The behavior 
of the continuous hydraulic press is realized via C code processing on SBCs. The 
implementation of the UML-PA model is realized semi manual. 

The interfaces to the existing UML model from the project IOSIP [15, 25, 28] 
are concerned during the development of this demonstrator. 

For realistic image the Reference Case Study is extended to evaluate the 
developed techniques and methods in the project DisPA [29]. To consider hard 
real-time aspects as well as automation control aspects, a further machining 
center is added. This machining center is a so-called continuous hydraulic press 
(figure 3). This is a part of a manufacturing plant from timber industry, which 
is the component with the most restrictive requirements. The whole plant mass- 
produces fibreboards. Time-critical closed loop control has to be combined with 
open loop control and switching to other control loops. For a better understand- 
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ing one feature is explained simplified in the following. The material, which is 
already mixed with glue, has to be pressed with a specific pressure to a certain 
distance due to the set value of the finished board’s thickness. 

In figure 3 this part of the continuous hydraulic press is shown. Such a press 
could be composed of almost 80 frames. Every frame has two distance sensors and 
from two to five hydraulic systems, that consist of a valve for pressure increase 
and pressure decrease as well as a sensor. The distance control is realized by 
these hydraulic systems. 

During the process the pressure has to be kept in a certain limit, but the 
thickness of the material (i.e. distance of the press gap, GiLs) should be reached. 
A maximum pressure is set because of technological reasons. The real hydraulic 
pressure (PICyiL) and the real distance (GiL) is measured additionally. 

The pressure has to be controlled in two modes: the distance control and 
the pressure control mode. Usually the continuous hydraulic press runs in the 
distance control mode. The distance control mode is the mode in which the set 
value of the distance is reached with the pressure between the upper and the 
lower limit. If the distance could not be reached within these limits, the mode 
is switched to pressure control. The difficulty is that all frames have to switch 
synchronously into the other mode and only in the case that all frames are 
currently capaple of changing their mode. Otherwise the press would stop. The 
closed loop control of each frame has to be accomplished in 30 ms. Only several 
frames are controlled by one processor. The specific frames are connected to the 
processors and the specific processors among themselves via field bus. 

4.3 GRASP 

In the GRASP project the specification language MFERT and visual behavior 
descriptions are integrated by using formal methods of specification. The 
method to validate formal properties is using simulation techniques. Here, the 
simulation tool shown in figure 1 was clevelopped in cooperation with the IOSIP 
project to illustrate the Reference Case Study Production Automation. As 
an extension of this simulation-based technique, local areas of the state space 
can be explored additionally. In this way, the validation of complex systems 
described in a highly detailed way becomes possible, whereas the validation was 
not possible so far because of complexity [13]. 



4.4 ISILEIT 

The main goal of the ISILEIT project is to develop a methodology to integrate 
design, tool-supported analysis and validation of distributed manufacturing sys- 
tems. Parts of the specification languages UML and SDL are used here. The 
integration of the models is performed by formally describing the operational 
semantics of the used specification techniques. In this way, the analysis and 
validation of the system models via model-checking and simulation becomes 
possible. 
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Within this project, a similar case study to the Reference Case Study is 
used. It is as well a flexible production system, containing several NC controlled 
processing machines and Scara robots. The material flow is realized by a rail- 
based system. In contrast to the Reference Case Study, the focus is not on lrolonic 
systems here, but on the integration of tools to create a tool chain. Thus the 
engineer is able to improve existing techniques with respect to formal analysis, 
simulation and automatic code generation [30]. 
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1 Introduction 

This chapter discusses a number of challenges to be fulfilled and considered 
regarding software specification for industrial engineering and control software 
within manufacturing systems. It does not provide an extensive list of detailed 
functionalities, but rather discusses generic critical success factors. The common 
thread is the complex interaction between software development and the techno- 
socio-economic context in which this activity occurs. The software development 
needs to produce much more sophisticated artefacts in the future, which requires 
developers to account for factors that could be ignored in the past. In the future, 
developers need to widen their view. This chapter describes in which ways they 
need to enlarge their scope. 

2 Software Implemenation Costs 

A first important challenge is to decrease the implementation costs of advanced 
concepts , like multi-agent or holonic manufacturing control [1, 2, 3, 4]. Today, 
this cost generally is prohibitive. The main reason is that such software currently 
is custom-developed for every single implementation. This means that costs can 
be spread neither over multiple customers nor over time. 

In the recent past, two types of effort can be distinguished in manufactur- 
ing control. First, there is the generative approach, in which a completely new 
and unique multi-agent manufacturing control system is generated at each oc- 
casion. This research aims to automate and systematize the software generation 
process as much as possible. The main motivation for this approach is that it 
generates systems with a small footprint, imposing low requirements on com- 
puter and communication resources; such resources are relatively expensive in 
manufacturing. This is however an artificial problem, mostly resulting from the 
geographical dominance of hardware vendors across the world. In manufactur- 
ing, computer and communication hardware is lagging mainstream computing 
significantly on cost-performance, but performance is nevertheless improving ex- 
ponentially (given fixed cost). Therefore, emphasis on modest hardware require- 
ments is an answer to a problem that will disappear eventually. 
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The second approach develops multi-agent manufacturing control systems 
that have as much software in common as technically feasible. This common part 
might be called a manufacturing operating system on which the customer-specific 
parts of the control systems are installed as applications. A first advantage of 
this approach is that multiple customers use this common software, which allows 
spreading development and maintenance costs. Hence, more economic effort can 
be spent on such common software parts than on specific implementations for a 
single factory. A second advantage is that the learning process for such software 
goes much faster. The software is used in more and more diverse situations, pro- 
viding feedback to developers from their users. As a consequence, such reusable 
software matures much more rapidly. A third advantage is that such a manu- 
facturing operating system necessarily possesses a wider operating range than a 
small-footprint specific control system. This means that it is more likely to cope 
with changing circumstances in the manufacturing system, probably benefiting 
from the experience in other places that came across similar situations already, 
without requiring any software maintenance. 

The advantages of the second approach are self-reinforcing: if some software 
is better, it attracts more users, more economic resources and more information 
feedback, which makes it even better, and the self-reinforcing loop is closed. Such 
software is likely to dominate as soon as one such implementation succeeds in 
the market. Most importantly, only this type of software is able to mobilize the 
significant amount of economic resources needed to have successful sophisticated 
software systems in manufacturing. As long as each implementation has to bear 
its efforts in isolation, the software will remain costly and primitive. A larger 
hardware footprint is a small price to pay for these more powerful solutions when 
seen on a medium-range perspective. 

In conclusion, the important future challenge for software specifications is 
to support carving out what is common, reusable and long-lived. The most im- 
portant common parts should be specified explicitly to ensure that critical and 
sophisticated software only has to be implemented once and can be used in 
factories all over the world during extended periods of time. 

3 Exception Handling 

Exception handling must become exceptional. Software specifications must ad- 
dress non-nominal but common situations as normal. For instance, control soft- 
ware must not assume that configurations remain unchanged or that any change 
will be communicated in time. Instead, systems constantly will have to rediscover 
configurations and forget stale data collected in the past. 

A valid exception is for instance a computer crash or a computer network 
malfunction. In contrast, examples of what often are considered exceptions today 
and should not be considered to be exceptions at all are: 

— Late delivieries 

— Equipment malfunctions and maintenance 

— Test results indicating the need for repair 
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— Rush order entries 

— Equipment replacement 



In other words, changes and disturbances in the underlying manufacturing 
system must be business-as-usual to the software; the software must cope with 
any possible life cycle of the underlying system. Computer crashes or a faulty 
database, triggering system restore operations, are the real exceptions. 

Software specification technology should encourage designers to consider 
more than the nominal trajectories, configurations etc. of the production systems 
as it operates today. This requires, among others, the emergence and dissemina- 
tion of a number of design templates and guidelines that enable the development 
of such robust systems. 

4 Reusable Software Components 

Software specification needs to enclose and support design methodologies that 
create effective reusable software components. Software specification technology 
encourages, by its nature, which type of components will be developed/specified. 
Not all types are suitable for integration, especially in dynamic and demanding 
environments. 

Consider traffic as analogy. Maps are highly reusable components when solv- 
ing navigation problems. In contrast, route descriptions are very fragile compo- 
nents with limited application. Even worse would be traffic regulations for trucks 
as a separate component from traffic regulations for cars. Manufacturing con- 
trol software devel-opment needs to catch up with modern software development 
technology. More than the specification language, the design approach needs to 
be addressed. 

Modern software engineering no longer prescribes functional requirements as 
the main starting point for the development. In the initial phases, a business 
case describes why the envisaged software development makes sense. Next, a 
number of ’use cases’ provide ’points solutions’ in the continuum that the soft- 
ware needs to cover by design. Then, a rough outline of the system architecture 
provides a backbone to the software development activity. The first detailed de- 
velopment activities focus on the so-called ’essential model’ [5] . This is our map 
in the navigation applications. An essential model reflects the relevant parts of 
the world for the software application and adds the functionality (sensors and 
actuators) to keep the essential model synchronized with the world. Finally, the 
user functionality is added incrementally. 

Essential models and parts of essential models are very likely to be highly 
reusable. For instance, a model of a conveyor belt is reusable wherever such a 
conveyor belt is used and as long as these belts are used. Note that integration 
issues will be cosmetic (e.g. syntax issues) since the software components corre- 
spond to parts of a real world that actually fits together (think of maps of parts 
of the world). Functional components never achieve this level of reusability and 
integrate-ability. 
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Summarizing, software specification technology needs to adopt the proper 
methodologies, which emphasize essential modelling (sometimes called concep- 
tual modelling) as the main activity in the initial phases. This is more important 
than adopting fancy modelling languages. 

5 Make Use of Mainstream Development 

Manufacturing software needs to ride on mainstream development waves. Man- 
ufacturing cannot afford the investments needed to reinvent mainstream IT. 
Mainstream IT reflects the highest level of sophistication that can be born by 
its extensive user community. Manufacturing, a much smaller community, cannot 
hope to match this on its own. When mainstream IT fails to deliver specific func- 
tionality, manufacturing must first look at solutions that add this functionality to 
mainstream IT, not solutions that require the reimplementation of mainstream 
IT. 

Alternatively, the manufacturing community may proactively influence the 
mainstream community to provide the extra functionality that is vital for man- 
ufacturing applications. The challenge is to follow mainstream developments 
closely, identify what is missing, and find sufficient allies, which also benefit from 
the enhancements needed by manufacturing, to push the desired enhancements 
into the mainstream developments. Fortunately, manufacturing is finding more 
and more natural allies for this in the multimedia, high-quality communication 
and computer games communities. 

Ethernet penetration, in its high-performance implementation, is an illus- 
tration of this phenomenon in the past. USB and FireWire are examples of 
mainstream competitors for Fieldbus technologies. Wireless communications is 
another domain in which mainstream developments are likely to dominate. Com- 
puter operating systems, web technologies, computer languages and multi-agent 
platforms [6] also are elements in the mainstream that impact on manufacturing 
software system developments. 

Software specification technology must not expect every manufacturing user 
to enter the information about mainstream systems; important mainstream sys- 
tems and standards should be supported within the software specification tool 
itself. Moreover, the mainstream has its own software specification technology. 
Manufacturing should not re-invent it, but add its specific functionality to it 
and influence the design of future versions of the mainstream software design 
technology. 

6 Co-design of a Manufacturing System and Its Control 
System 

In practice, the design and development of a manufacturing control system ac- 
tually is a co-design of the manufacturing system and its control system. Con- 
sequently, a software specification environment must seamlessly integrate with 
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a manufacturing system specification environment. Indeed, the control software 
being specified can only be properly defined in relation to the underlying pro- 
duction system(s). 

In such a co-development exercise, most decisions, impacting economic per- 
formance, are taken before the production system is built or modified or the 
control system is deployed. Consequently, there is a need to elaborate the con- 
trol system connected to an emulation of the underlying production system. 

Moreover, this configuration must support experimentation campaigns that 
provide reliable information about the performance of such a system when ac- 
tually deployed. Therefore, it needs to support the necessary functionality, some 
of which is not available in any commercial systems. An example is the com- 
bination of real-time emulation while the control is ’thinking’ with event-based 
emulation when the control system is inactive. Another feature is support for 
dithering/jitter on timing of control action triggers in combination with execut- 
ing sufficient replications such that the variation in behaviours of the deployed 
system is properly estimated. At lower levels of control, the emulation must even 
reflect the time-continuous behaviour of manufacturing processes. Overall, this 
is an area in which a significant amount of research and development is needed. 



7 Conclusions 

This chapter lists some important requirements concerning software specification 
for industrial engineering and control software within manufacturing systems. 
These requirements do not list specific functionalities that are needed in the 
future. The chapter addresses more generic aspects: 

— Achieving large, long-lived and diverse user communities for the software 
to be able to create and maintain solutions exhibiting an unprecedented 
increase in so-phistication and user functionality. 

— Handling disturbances and changes in the manufacturing environment as 
business as usual. Exception handling has to be restricted to malfunctions 
and failures related to the computer infrastructure, not the underlying in- 
dustrial systems. 

— The community needs to support state-of-the-art software engineering meth- 
ods and more specifically essential models as reusable software components. 
It must develop reusable components that are for manufacturing control 
problems what maps are for navigation. 

— The technology must facilitate to ’ride the mainstream wave.’ Again, size 
and diversity of the user community is the key success factor. 

— The software specification support needs to address the wider issue of soft- 
ware and manufacturing system co-design. This is the phase in which most 
of the investment decisions are made. Designing software as an afterthought 
and without a solid link to the related underlying manufacturing system is 
unworkable in the longer run. 
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Overall, software in industrial engineering and control within manufacturing 
systems is about to make a quantum leap in sophistication. The enabling infor- 
mation technologies exist and constantly penetrate the manufacturing world at 
increasing speed. The above addresses key success factors to make this happen. 

Acknowledgement. This chapter was written in the framework of research 
sponsored by the Research Council of the K.U. Leuven. 

References 

1. Valckenaers, P., Van Brussel, H., Hadeli, Bochmann, O., Saint Germain, B., Zam- 
firescu, C.: On the Design of Emergent Systems: an Investigation of Integration 
and Interoperability Issues. In: Engineering Applications of Artificial Intelligence 
16 (2003) 377-393. 

2. Bussmann, S. and Schild K.: Self- Organizing Manufacturing Control: An Industrial 
Application of Agent Technology. Proc. 4th Int. Conf. on Multi-Agent Systems, 
pp. 87-94 (2000), Boston, MA, USA. 

3. Valckenaers, P., Van Brussel, H., Kollingbaum, M., Bochmann, O.: Multi-agent co- 
ordination and control using stigmergy applied to manufacturing control. In: Lecture 
Notes in Artificial Intelligence, Vol. 2086 (2001), Springer, Berlin, pp. 317-334. 

4. Parunak, H.V.D., Baker, A.D. and Clark, S.J.: The AAR.IA Agent Architecture: 
An Example of Requirements-Driven Agent-Based System Design. In: Proceedings 
of the First International Conference on Autonomous Agents (1997), pp. 482-483 
Marina del Rey, CA. 

5. Cook, S., Daniels, J.: Designing Object Systems. Prentice-Hall, 1994, London. 

6. The foundation for intelligent physical agents, http://www.fifa.org, April 2004. 




Development of Hierarchical Broadcasting Software 
Architectures Using UML 2.0*’** 



Ingolf Kruger 1 , Wolfgang Prenninger 2 , Robert Sandner 3 , and Manfred Broy 2 

1 Department of Computer Science & Engineering, University of California, 

San Diego, La Jolla, CA, 92093-0114, USA, ikrueger@ucsd.edu 
2 Institut fiir Informatik, Technische Universitat Miinchen, 

D-80290 Munich, Germany, {prenning I broy}@in . turn . de 
3 BMW AG, D-80788 Munich, Germany 
robert . sandner@bmw . de 



Abstract. The definition of a transparent software architecture is one of the key is- 
sues in the early development phases for complex distributed and reactive software 
systems. We show how to derive an architecture systematically for systems with 
communication models based on broadcasting. Adequate graphical description 
techniques for capturing interaction requirements and logical component archi- 
tectures for broadcasting systems are unavailable so far. We introduce an extension 
to UML’s sequence diagrams to capture broadcasting scenarios. Furthermore, we 
present methodological steps for constructively deriving structural and behavioral 
aspects of the architecture under consideration from the captured scenarios. 



1 Introduction 

Broadcasting is the central communication paradigm in practical embedded system ap- 
plications, as found in the automotive, avionics and wireless communications domains. 
The increasing complexity and interconnection of such systems calls for a careful iden- 
tification and documentation of their logical software architecture. Adequate method- 
ological support for architectural modeling is, however, limited to point-to-point (p2p) 
communication paradigms so far. In this paper we address this challenge by providing 
notational and methodological extensions to UML 2.0 [1], leading to an architecture- 
centric approach to the analysis & design of broadcasting-based embedded systems. 



The Importance of Software Architecture. A decisive step in the development pro- 
cess for complex distributed and reactive systems is the identification of an adequate 
software architecture; this is especially important for long-living systems and products 
where adaptability to changing requirements, but also correctness and quality are major 
concerns. 

A software architecture, in our view, comprises three central ingredients: the (hi- 
erarchical) decomposition of the system into components, the precise specification of 

* Our research was supported by the Deutsche Forschungsgemeinschaft within the priority pro- 
gram “SoftSpez” (SPP 1064) under project name InTime. 

** This paper is a revised version of [16]. 
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the roles and the relationships (often called interfaces) between these components, and 
the forces and constraints that govern the chosen decomposition and component rela- 
tionships (cf., for instance, [4,5,10] for other definitions of this term). A key issue in 
creating a software architecture is, therefore, the decomposition of the system under 
consideration, and the definition of clear component interfaces. 

The importance of system decomposition, as well as of structural and behavioral 
aspects of component interfaces induces challenges at our approach to system devel- 
opment: How to represent the structural and behavioral aspects of an architecture in a 
concise yet comprehensive way? Can we systematically turn captured requirements into 
an initial architecture? For a set of captured requirements, is there hope for automatic 
construction of components such that they fit into a given architecture? How to refine 
the components thus obtained without destroying the selected architecture? 

In the remainder of this text we deal with these challenges especially in the domain 
of distributed, reactive systems whose components employ broadcast communication. 

UML 2.0: Modeling Architectural Aspects. To represent the important architectural 
aspects outlined in the preceding subsubsections we employ the notation of UML 2.0 for 
modeling structures [3,1]. UML 2.0 adopted the concepts of mature modeling languages 
ROOM [ 19] (Real-Time Object-Oriented Modeling) and SDL [9] (Specification and De- 
scription Language) in order to support specifying components and system architectures 
of real-time applications. 

For a thorough understanding of UML 2.0’s recently added capabilities for mod- 
eling system architectures we refer the reader to the citations already given. Here it 
suffices to observe that UML 2.0 provides graphical description techniques for captur- 
ing hierarchical structural decomposition (via structure diagrams and class diagrams), 
asynchronous point-to-point (p2p) component interactions (via sequence diagrams), and 
individual component behavior (via state machines). These notational elements cover al- 
ready most of what we have identified above as essential for representing architectures. 
In the following we assume familiarity with the UML’s class diagram notation, and 
concentrate briefly on structure diagrams describing structured classes, and sequence 
diagrams; these are the major models we work with in subsequent sections. 

We start with a brief overview of UML 2.0’s component model. A structured class 
in UML 2.0 represents a potentially active component whose communication with its 
environment proceeds by means of asynchronous signal exchange via its ports. A port 
is an interface point between a class’s internals and its environment through which 
messages are sent either into or out of the class. The outgoing and incoming messages 
of a port are specified by so called required and provided interfaces, respectively. A 
structured class can be hierarchically decomposed into parts. Each part represents the 
use of a class in the context of the containing class. The ports of the parts are wired by 
connectors that establish p2p communication links between different ports. In the context 
of structured classes an interface consists of a set of signals. Depending on the role 
required or provided in association with a port the interfaces defines the messages sent 
and received through a port. The ports are graphically represented by outlined squares. 
Optionally the provided and required interfaces of a port are graphically represented by 
"lollipop” and "socket” notation, respectively. Figure 1 shows an example of a structure 
diagram of a structured class; we explain the details of this diagram in Section 4.2. 
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Fig. 1 . Structured classes 



Structured classes can nest hierarchically to arbitrary depth by means of decomposing 
their parts; an enclosing class communicates with its parts also via ports and connectors 
just as it does with its environment. There is no means for accessing the internals of a part 
directly from the environment of their container. The behavior of each structured class 
must, in particular, conform to the interfaces the class commits to via its port definitions. 

UML 2.0 suggests the use of sequence diagrams (SDs, for short), a variant of Message 
Sequence Charts [8,11] (MSCs) for modeling interactions. Figure 2 shows an example 
of an SD. It depicts a certain section of the communication among the four components 
W, X, Y, and Z within an imaginary distributed system. In this figure, labeled axes 
represent components, whereas labeled directed arrows indicate message exchange from 
the source (at the arrow’s tail) to the destination component (at the arrow’s head). Time 
advances from the top to the bottom of the figure; this induces a temporal order on the 
depicted messages. Intuitively, Figure 2 captures a situation where Y and Z, in turn, send 
the message subscribe to X. Then, X receives message update from W. Subsequently, 
X sends message notify to Y and Z (in that order). Upon receipt of message notify, 
component Y sends message request to W, and receives message reply in return. 

This simple example already allows us to illustrate one of the strengths of SDs. They 
contain information on the distribution structure, as well as on the interaction behavior of 
the system under consideration. This combination helps to make explicit the coordination 
aspect of system behavior, beyond the local scope of individual components. SDs, such 
as the one in Figure 2, show one particular interaction pattern (or scenario) among the 
depicted components; there are possibly several other such patterns differing from this 
particular one. In this sense, SDs complement other forms of specification that capture 
the complete behavior of individual components. Unless stated otherwise we view all 
SDs as scenarios in the remainder of this text; we refer the reader to [11,13] for other 
SD interpretations. 




32 



I. Kruger et al. 





:W :X :Y :Z 




update 




_ subscribe 



subscribe 




notify 


notify _ 


request 




reply 










Fig. 2. Simple sequence diagram 



Broadcasting vs. UML 2.0’s Communication Model. From our brief presentation of 
the novel descriptions techniques in UML 2.0 in the preceding subsubsections it should 
be clear that UML 2.0 has strengthened in architectural modeling of systems based on 
p2p communication. Unfortunately, UML 2.0 has no adequate notational or method- 
ological support for broadcasting. However, because broadcasting is so fundamental in 
many technical applications, description techniques and methodological steps for cap- 
turing architectural requirements concisely are particularly desirable for this application 
domain. 

To reconcile the hierarchic, p2p-based communication model built into UML 2.0 
with broadcasting - without drastic changes to UML’s description techniques - we in- 
troduce a combination of three methodological tools in this paper. First, we suggest to 
integrate the notion of broadcasting into the system’s architecture instead of dealing 
with it by resorting to special-purpose description techniques, such as the full statechart 
notation 1 . We define dedicated message mediators at appropriate places in the system’s 
architecture; the purpose of these mediators is to distribute and filter the broadcast mes- 
sages relevant for particular sub-trees in the component hierarchy. Second, we introduce 
a graphical description technique, a slight extension of the UML’s SDs, for capturing 
broadcasting scenarios for the services provided by sets of components. Third, we pro- 
vide transformation procedures for deriving component structure and behavior from the 
captured scenarios. This allows us to use the scenarios constructively in deriving the 
system’s architecture at all levels of the structural hierarchy. 

An Integrated, Architecture-Centric Development Process for Broadcasting in 
UML 2.0. From these methodological tools we obtain an integrated methodology for 
deriving interfaces for broadcasting systems using UML 2.0. The idealized development 
process we follow starts with the capturing of all relevant entities and their (structural) 

1 The statechart notation as introduced in [7] employs a broadcasting-based communication 
model. 
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relations in the system under consideration in a class diagram. We call the resulting model 
the system’s domain model. Then we identify those entities in the domain model which 
are active components and capture their relevant interaction patterns using broadcast 
sequence diagrams. These interaction patterns cover architectural manifestations im- 
posed by the requirements explicitly: components and the communication paradigms. 
This enables us to derive prototypical component structures and behaviors including 
interfaces for both p2p and broadcast communication within the system which can be 
refined in subsequent development steps. Following the architectural scheme of intro- 
ducing dedicated message mediators on all levels of the component hierarchy enables 
uniform treatment of component refinement; this allows us to perform the development 
process described so far in a truly iterative, top-down fashion. 



Overview. The remainder of this text is structured as follows. In Section 2 we describe 
the running example - an autonomous transport system - we use to illustrate our ap- 
proach. The architectural pattern we use to handle broadcasting within the framework 
of UML 2.0 is the topic of Section 3. In Section 4 we describe our sequence diagram 
extensions for representing broadcast messages, as well as the constructive transition 
from scenarios to component structure and behavior. Section 5 contains our conclusions 
and an outlook. 

2 A Running Example 

In order to illustrate our methodology we use an early version of the DFG reference case 
study “Production Automation” [6] which is an autonomous transport system within a 
production plant. This system transfers workpieces from their present location to another 
one where the next production step is then carried out. In the beginning, fresh workpieces 
reside in an “in store”. Workpieces whose processing is finished are transported to an 
“out store”. Machine tools perform the actual processing of workpieces. Whenever a 
machine tool is free it requests to obtain a workpiece, which is then delivered by an 
autonomous vehicle (termed “holonic transport system”, or “HTS” for short). 

Machine tools and HTSs use broadcasting to negotiate the delivery of a workpiece; 
a machine tool broadcasts its requests to all HTSs; the HTSs, in turn, broadcast their 
offer (an estimate on how long it takes them to satisfy the request). Finally, the machine 
tool broadcasts which HTS has “won the deal”. 

The domain model of Figure 3 captures the mentioned entities, as well as a few 
additional ones, in the form of a UML 2.0 class diagram. The entire production is driven 
by a production plan, modeled by class ProdProg. This plan defines, among others, 
the required daily throughput of workpieces. The classes Database and Status model 
the storage of information about the HTSs’ and machine tools’ view of the current state 
of the production process. Job is the class for modeling the pick-up tasks negotiated 
between machine tools and HTSs. The destination of an HTS to pick up a workpiece is 
captured by the class Location. We take the class BroadcastSystem as the explicit 
architectural manifestation of the requirement to use broadcasting in the p2p communi- 
cation model of UML 2.0. By means of this domain model we have covered the logical 
associations between the classes of the system under consideration. The corresponding 
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Fig. 3. Domain model 



communication paths will be identified by developing interaction scenarios (cf. Sec- 
tion 4.1). Furthermore, the domain model is the starting point for deriving an initial 
architecture (cf. Section 4.2). 



3 An Architectural Pattern for Broadcasting 

We face different options in modeling a software architecture supporting broadcast com- 
munication. We could, for instance, select a broadcasting-based execution model as pro- 
vided by standard statecharts [7], and avoid the p2p communication model used in UML 
2.0’s composite structures right away at the beginning of requirements analysis. 

As a consequence we would, however, commit to a very design- and implemen- 
tation-oriented description technique and an execution model at a very early stage in the 
development process; in particular, there would be no clear separation of structure and 
behavior in the system decomposition. In addition to inheriting all of the other problems 
statecharts bring along with respect to their semantics (cf. [2] for an overview), we would 
lose much potential for systematic abstraction and refinement of individual components; 
this is due to the lack of clear component interfaces in statecharts. 

Another approach would be to introduce and abuse specialized ports in UML 2.0 
like they are provided by ROOM as a connection between actor implementations and 
the runtime system they operate on. Relying on these service provision points (SPPs) 
and service access points (SAPs) yields an implicit, implementation-oriented solution 
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Fig. 4. Architectural pattern for broadcasting 



for establishing broadcasting. However, we aim at a more general solution for the prob- 
lem at the level of architecture (instead of implementation) which is also applicable 
beyond ROOM’S or UML 2.0’s tool support, respectively. In particular, more flexible 
communication regimes than pure broadcasting would lead to a proliferation of SPPs and 
SAPs; this, in turn, would contribute to obscuring as opposed to clarifying the system’s 
architecture. 

As we have outlined in Section 1 , we aim at a clear notion of a component and its inter- 
faces, as indispensable ingredients for defining and representing software architectures. 
Therefore, we stick with UML2.0’s novel component, interface, and communication 
model, and integrate broadcasting into this model by means of explicit components 
within the software architecture we aim at. 

The design we suggest is a variant of the recursive control and subsystem controller 
patterns described in [18] and [5], respectively. Consider Figure 4 for an overview of the 
basic structural decomposition we associate with components in our architecture. We 
distinguish three kinds of components: 

- leaf components, which form the leafs of the component hierarchy, 

- broadcasting components, which play the roles of containers for leaf components, 
nested broadcasting components, and an IO system, 

- IO system components, which act as mediators for broadcasting messages received 
or generated by their container. 

The idea is that every hierarchically decomposed component has an IO system, 
which handles the broadcasting of messages among the relevant subcomponents of 
the container, and between the container and its environment. Intuitively, to perform 
a broadcast, a component sends a message to the IO system of its container. This IO 
system is then responsible for distributing this message to all other relevant components 
within the container, as well as to the IO system of the container’s parent in the component 
hierarchy. This ensures that all broadcast messages reach all components participating 
in the broadcast communication. In Section 4 we describe the concrete realization of 
this protocol scheme in more detail. 

We note several benefits of this architectural pattern. First, the hierarchic structur- 
ing of broadcasting components enables direct application of classical techniques for 
top-down structural system design. From the viewpoint of broadcasting to refine a com- 
ponent structurally simply means adding a new IO system, and connecting it properly 
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(a) HTS domain (b) Disponent domain 

Fig. 5. Decomposed domain models 



to the refining sub-components, and to the container’s environment. This is directly 
supported by UML 2.0’s novel component and interface notion. Second, beyond their 
mere purpose of being mediators for broadcast messages the IO systems can also filter 
messages irrelevant for a particular subtree in the component hierarchy; this can lead 
to more efficient design and implementation strategies. Furthermore, components not 
participating in broadcasting need not to have connections to IO system components at 
all. Third, the switch from broadcasting to other communication paradigms is immedi- 
ately possible by simple redefinition of the purpose of the IO systems. According to the 
architectural pattern above we determine sub-domains for the class HTS of the running 
example. 



Example (continued). Figure 5(a) shows the internal structure of an HTS in more detail. 
The HTS is an example of a broadcasting component. In addition to Database the HTS 
contains the components here captured by the classes Disponent, Single JobControl 
and IOSystemHTS. Following the pattern introduced above the IOSystemHTS corre- 
sponds to the IO system component and handles the communication between the Broad- 
castSystem and the other subcomponents. The responsibility of IOSystemHTS includes 
also message filtering, i.e. the IOSystemHTS forwards only broadcast messages to sub- 
components which need this message. Disponent and SingleJobControl are responsible 
for the two main tasks of an HTS: negotiating jobs, and executing an acquired job, 
respectively. 

The disponent is also a broadcasting component. Its refinement is depicted in Fig- 
ure 5(b). The disponent contains the components IOSystemDisponent, Trader and 
Calculator. According to our pattern IOSystemDisponent is responsible for broadcast 
messages and connects the subcomponents of the disponent to the superior broadcast- 
ing component IOSystemHTS of the Disponent’s environment. Trader and Calculator 
conduct the negotiation and the computation of a bid for an order, respectively. 
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4 From Broadcasting Scenarios to Component Interfaces 

Now we link our guiding architectural pattern for dealing with broadcasting with method- 
ological steps for constructing both the system’s hierarchic decomposition, and proto- 
types for the behavior of its components, starting from interaction scenarios. 

In Section 4.1 we introduce extensions to the UML’s Sequence Diagrams (SDs) to 
capture scenarios for broadcasting interactions; we exploit the requirements captured by 
such scenarios to systematically construct important parts of the software architecture 
we target. Furthermore, we briefly discuss the notion of structural refinement which 
allows us to apply our methodological approach on all levels of structural abstraction. 
In Sections 4.2 and 4.3 we discuss the systematic derivation of component structure and 
behavior from captured broadcasting scenarios. 



4.1 Sequence Diagrams for Broadcasting 

As stated above, the precise description of component interaction is of particular impor- 
tance in defining an adequate architecture. Modeling component interaction both covers 
important aspects of the requirements analysis and is a first design step since it identi- 
fies “active” components among the entities defined in the domain model (Fig. 3). The 
major modeling technique of the UML employed in this step are SDs (see Section 1). 
Yet, SDs provide no notational means for dealing with broadcast communication. Fur- 
thermore, there is no sufficient methodological integration with other UML diagrams, 
such as statecharts. In this section, we show how SDs can be extended easily to model 
broadcast communication in addition to p2p communication, and to express relations 
to behavior models. To discuss these extensions, let us consider an application scenario 
of the autonomous transport system. Figure 6 shows a scenario for the negotiation of a 
transport task. 



Extending Sequence Diagrams for Broadcast Communication Patterns. Just as 
in classical SDs (as introduced in Section 1) labeled, vertical axes represent part of 
the behavior of the corresponding components in our extended SD notation. Labeled 
horizontal arrows indicate p2p communication. Broadcast communication is expressed 
by communication lines without arrow heads. An outlined circle marks the originator 
of the message and filled circles mark the receivers of the message. This allows us to 
model broadcast and even multicast communication succinctly. The semantics of the 
new communication construct is easily embedded into the semantics of “normal” SDs: 
Each broadcast line corresponds to a set of messages, each directed from the originator 
to one recipient. A formal semantics definition for broadcasting in the context of MSCs 
is defined in [15]. 

We use additional features of SDs for a succinct representation of interaction patterns 
like rectangular labeled boxes which denote local actions of a component, and states de- 
picted by labeled boxes with rounded corners. States appear on axes in our SDs; they 
identify control states of the corresponding component. Using states we can combine 
SDs to more complex scenarios: Different SDs starting with the same state label express 
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Fig. 6. Broadcast SD for scenario “order negotiation" 



nondeterministic choice; SDs starting and ending with the same state label indicate rep- 
etition. Both simple and composite SDs should be understood as exemplary interaction 
patterns (scenarios) in the sense of [ 1 1,12], not as complete behavior specifications. 



Example. In the example of Figure 6, a machine tool announces an order using broadcast 
communication. Each HTS calculates the time it needs to satisfy the request within the 
locally performed action compute bid. In this scenario, two HTSs announce a bid for 
the order and finally, after the machine tool ends the negotiation, the HTS denoted by 
h has won the deal. After the negotiation, the HTS components reside in the same state 
as they started. Figure 7 shows a combination of broadcast and p2p communication 
occurring during the execution of a transport: When the HTS arrives at a machine tool 
to pick up a workpiece, it sends a request to the machine tool which, in turn, responds 
by a release message. Finally, the HTS announces the picking up of the workpiece by 
means of a broadcast message. 

Hierarchic Component Refinement: Integrating the Architectural Pattern with Sys- 
tematic SD Usage. In Section 3 we have introduced an architectural pattern for dealing 
with broadcasting messages in a hierarchic decomposition of the system under consid- 
eration. We mimic this notion of decomposition by introducing a notion of structural 
refinement for axes within broadcasting SDs. Before performing a structural refinement 
we view the component corresponding to the axis under consideration as a “black box”, 
and do not care about how this box internally handles the messages it receives. Afterwards 
the component has become a “glass box”, i.e. we have additional knowledge about its 
internals that we can refer to in our specifications. Intuitively, a decomposed component 
relays all messages it receives from its environment (and does not want to react on itself) 
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Fig. 7. Broadcast SD for scenario “picking up a workpiece” 



to its subcomponents; similarly, it relays all messages received from its subcomponents 
via its own interfaces to the environment. We explain UML 2.0’s notion of structural 
refinement, which directly corresponds to the idea outlined here, in Section 4.2. 

For a structurally refined component within an SD we add further SDs represent- 
ing the communication patterns within the refined architecture. These SDs capture the 
interactions among the refining components, as well as the relay of messages between 
the refined and the refining components. In the decomposition we respect the following 
important rule: the SDs of the decomposed view have to be consistent with SDs of the 
non-decomposed view. Messages arriving at the refined component in the abstract SD 
must also occur (as relayed messages) in the refining SD; similarly, messages emanating 
from the refined component in the abstract SD must also occur (as relayed messages) 
in the refining SD. We represent messages sent to or received from the environment of 
a refining SD by lines and arrows ending or originating at the bounding box of the SD, 
respectively. For a formal treatment of structural refinement within sequence diagrams 
see [11]. 



Example (continued). In the following we turn our attention to the running example 
again, and derive SDs for the different hierarchic levels for HTS and Disponent intro- 
duced in Section 3. Figures 6, 7, 8 and 9 depict a subset of the scenarios related to the top 
level domain (cf. Figure 3) and different decomposed levels (cf. Figure 5), respectively. 

As an example for structural refinement we decompose the axis corresponding to 
component h : HTS in the scenario for order negotiation (cf. Figure 6). The decomposition 
of this axis is shown in Figure 8; it respects the architectural pattern introduced in Section 
3 (cf. Figures 4 and 5(a)). The refined SD shows the internal interactions within the 
FITS, which are necessary to decide whether a bid is submitted for an order, and to 
check whether the negotiation has been successful. The messages exchanged between 
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Fig. 8. Refined HTS axis 



IOSystemHTS and the environment of HTS match with the messages associated with 
the h : HTS axis of Figure 6. 

In Figure 9 we show the next hierarchical level according to the domain model of 
Figure 5(b), obtained by refining the disponent axis in the SD of Figure 8. After the trader 
has received an order message from the IOSystemDisponent, the calculator computes 
a bid, respecting the status received. Then the trader conducts the further negotiations 
with the aid of IOSystemDisponent. 

The refined scenarios in Figures 8 and 9 show that every message according to broad- 
casting is relayed via the IOSystem axis as claimed in Section 3. Our next methodological 
step is to take the captured scenarios as a starting point for constructively deriving struc- 
tural and behavioral aspects of the architecture under consideration. 

4.2 Component Structure 

Recall from Section 1 that an important part of a software architecture is the decomposi- 
tion of the system under consideration. We use UML 2.0’s hierarchic structure diagrams 
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for representing system structures. Consider, as an example, the structure diagram of 
Figure 1; it displays items for the HTSs, the stores, the machine tools, and broadcast 
system as an exemplary subset of the entities contained in Figure 3. Each member of 
this set is a part of the structured class ProdSys. Every FITS has connectors to each of 
the stores, as well as to every machine tool, with corresponding ports. Moreover, there 
exist connectors between the HTSs and the broadcast system; similar connections exist 
for the machine tools and the out store. 



Systematic generation of component structures. In the following, we suggest a 
method for developing structure diagrams using the knowledge captured during require- 
ments analysis, and expressed via the domain model and the SDs of Section 4. 1 . We 
show how structured classes, its interfaces and its wired parts can be derived systemati- 
cally and discuss the embedding of broadcast communication using these concepts. The 
model we obtain serves as a starting point for the development of a system design, which 
can be completed, generalized, and optimized by subsequent refinement steps. The ad- 
vantage of the proposed procedure is that we obtain consistency with the requirements 
analysis by construction. 
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We start with an overview of the steps to get a first sketch of a structure diagram. We 
assume that, starting from the domain model, the active components have been identified 
already by capturing interaction scenarios, as shown in Section 4.1. The procedure 
consists of three phases: First, the container class and its parts describing the system 
are defined (steps 1+2, below). Second, interfaces are derived from the SDs (step 3). 
Third, the interfaces are assigned to ports which are linked by connectors (steps 4+5). 
The methodical steps are as follows: 

1 . Create a container class which will contain the entire parts identified in the further 
steps 2 . 

2. a) Create a part in the container for each class which appears in the SDs as an axis, 
b) Create a part which performs the broadcast message passing, if broadcast com- 
munication occurs between axes in the SDs under consideration. We call this 
part broadcast system in the following. 

3. a) Create up to two interfaces for each pair of classes which exchange regular 

messages in SDs. Include all messages belonging to one of the communication 
directions into one of these interfaces, respectively, 
b) If necessary, create individual interfaces for each class which uses broadcast 
communication. 

4. Assign to each class its respective ports associated with the respective interfaces 
created in previous step. 

5. Establish a connector in the container class between any two ports derived from p2p 
communication interfaces; establish a connector in the container class between any 
port derived for broadcasting and the broadcast system. 

Steps 3 through 5 are straightforward for p2p communication: After interface gen- 
eration we just need to create a port which associates a provided or a required role to 
these interfaces, respectively, and link this port to the port of its communication partner. 
Unfortunately, we cannot use connectors and ports in such a straightforward way for 
broadcast communication, because in general there are more than two communication 
partners involved. 

Instead, we handle broadcasting by introducing an explicit class for broadcast com- 
munication, in line with the architectural pattern introduced in Section 3. Each class 
which is involved in broadcast communication is equipped with a port connecting it to 
this broadcast class (step 3(b)). This approach models broadcasting explicitly. 



Example. By means of our running example we illustrate the methodological steps 
introduced above: First we create the structured class ProdSys which will embed all 
parts of the system communicating at top level (step 1). Then we derive the parts of 
type HTS, InStorage, OutStorage and MachineTool from a set of top level SDs 3 to 
be embedded in the container (step 2 (a)). Since broadcast communication is used in 
these SDs we create a part of type BroadcastSystem (step 2 (b)). For the generation of 
interfaces, let us consider the handshake communication HTS ++ MachineTool. From 

2 UML 2.0 requires a top-level container for all parts of the system. 

3 Two examples are shown in the Figures 6, 7. 
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Table 1 . Protocols 



«interface» 

iRequest 


«interface» 

iBroadcastMT 


requestWPO : void 
requestPlace() : void 


jOrder(jobno,m ) : void 
jEndofNegotiation(jobno) : void 



interfaced 




«interface» 


iRelease 




iBroadcast 


releaseWPQ : void 




jBid(jobno) : void 


releasePlaceQ : void 




jTransportingtjobno) : void 


(a) 


jFinished(jobno) : void 



(b) 

the SDs, the interfaces iRequest and iRelease are created. Table 1(a) depicts these in- 
terfaces. Analogously we proceed with other pairs of communicating capsules (step 3a). 
For broadcast communication we consider every class participating in broadcast commu- 
nication. We create an individual interface containing messages which each class sends 
and a common interface which contains all broadcast messages received by all classes. 
Table 1(b) shows the individual interface iBroadcastMT for class MachineTool and 
the common interface Broadcast for all broadcasting classes (step 3(b)). Every class 
gets its ports with appropriate interfaces according to its communication roles, e.g. class 
MachineTool gets a port providing interface iRequest and requiring interface iRelease 
and a port providing interface iBroadcast and requiring interface iBroadcastMT (step 
4). Finally the connectors between the related handshake ports and between broadcast 
ports and broadcast system are added in the structure of class ProdSys (step 5). The 
result is a first prototype of the system’s structure diagram. Clearly, we have to adjust 
the cardinality of the parts HTS and MachineTool to their required number, as given in 
a concrete instance of the system. The resulting structure diagram is shown in Figure 1 . 



Hierarchical decomposition. At nested hierarchical levels the generation scheme can 
be simplified. Step 2(b) and 3(b) are omitted, because broadcast communication is only 
performed in the top level SDs. In decomposed views broadcast messages are distributed 
by respective IOSystems. Thereby broadcast communication is transformed to p2p com- 
munication and only relevant messages are forwarded. Step 1 is omitted, because the 
container class with its public ports is already given by the previous generation of the 
more abstract level. 



Example (continued). As an example, we use the SDs of the decomposed HTS view 
(one of them is depicted in Figure 8) to derive the structure diagram of the class HTS 
in Figure 10(a). According to step 2(a) we derive the parts of type IOSystemHTS, 
Disponent, Database and SingleJobControl. Creating interfaces, assigning ports 
and establishing connectors for internal p2p communication is treated as before. 
However, there is a new kind of p2p communication between parts and environment 
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(a) Capsule diagram of HTS 




(b) Capsule diagram of Disponent 
Fig. 10. Decomposed structure views 



of HTS, for example IOSystemHTSoenvironment. Hence there must already exist 
interfaces which contain these messages and public ports associated to the respective 
interfaces. In fact this is true for the interfaces iBroadcastHTS and iBroadcast (Tab. 1(a)) 
and the respective port in the example under consideration. Thus, we can omit creating 
interfaces for those communication partners. Only a respective port has to be assigned 
to the class and in structure of class HTS the port of the corresponding part has to be 
connected to the respective public port. This works gracefully because we obeyed the 
rules of structural refinement in developing the SDs. 

Analogously we derive the structure of the class Disponent of Figure 10(b) by means 
of SDs such as the one shown in Figure 9. 
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4.3 Component Behavior 

In this section, we give a rough sketch of the derivation of behavior specifications of the 
system components from the scenarios collected during the requirements analysis. Again, 
this development step can be carried out automatically, using the algorithm presented 
in [13]. This algorithm takes a set of sequence diagrams as input, and generates an 
automaton specification for the component under consideration as output. This algorithm 
employs the state labels introduced in Section 4.1 to determine execution orderings 
between the specified scenarios. It consists essentially of four steps: 

1 . Projection: After having selected the component for which we want to construct an 
automaton, we project each of the given SDs onto this component, 

2. Normalization: We determine the transition-path segments defined by the projected 
SDs, according to the state labels appearing in the SDs; if necessary, we add appro- 
priate state labels at the beginning and at the end of the projected SDs, 

3. Transformation into an automaton: We turn every message arrow appearing in an 
SD into a transition of the automaton; if necessary, we add intermediate states to link 
transitions, such that they correspond to a sequence of messages within a normalized 
SD, 

4. Optimization: We apply heuristics, or use algorithms known from automata theory 
for automaton minimization. 

As an example, let us consider the part of type trader appearing in Figure 10(b). The input 
source for the generation of a statechart of the class is the SD in Figure 9. The states on 
the axis of the trader express that the execution ends in the same state as it started (named 
idle). Two further state conditions on bids and names of bidders allow the truncation 
of the negotiation; they yield a split of the SD into three parts at this point in step (2) of 
the transformation procedure. These state conditions allow us to specify alternatives at 
this points which we have omitted here for brevity. For a detailed model, we refer the 
reader to [ 14]. An automaton resulting from the generation which does include choices 
is shown in Figure 11. Note that this statechart has to handle only the messages relevant 
for the trader. 

5 Conclusions and Outlook 

We have presented an approach at incorporating broadcast communication into the mod- 
eling of architectural design using UML 2.0. To that end, we have introduced and em- 
ployed an architectural pattern for capturing broadcasting by means of explicit compo- 
nents on all levels of the component hierarchy. This introduces broadcasting seamlessly 
on the basis of UML 2.0’s p2p communication model in the area of composite structures. 
Dealing with broadcasting explicitly on the level of a logical architecture of the system 
under consideration has several advantages. It supports classical top-down structural 
system decomposition, and introduces a flexible, adaptable, and configurable commu- 
nication mechanism we can exploit during further stages of requirements analysis and 
specification. 

We have also shown that by means of only few syntactic extensions we can employ 
the UML’s sequence diagrams for transparently capturing broadcasting scenarios. This 
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Fig. 11. An optimized statechart for the trader 



enables concentrating on use cases and service-oriented specification techniques also in 
the development process for broadcasting systems. Making these extensions an integral 
part of the language allows both for a compact modeling of broadcasting and for adopting 
these aspects systematically into the systems architecture. Furthermore, integration of 
timing aspects, such as the durations of communications, can be easily integrated along 
the lines of what is already available for regular sequence diagrams in the UML [1,17], 

Prototypical models can be generated automatically from broadcasting scenarios 
captured by means of SDs. The resulting diagrams provide a high level architecture 
description and are ideally suited to serve as a starting point for the actual design of the 
system to be developed, because they guarantee consistency with the requirements anal- 
ysis by construction. The initial architecture can be refined in subsequent development 
steps: For example, new messages can be introduced or entire interaction interfaces can 
be reorganized in order to develop more general interfaces used by strutured classes. A 
structuring of these development steps can be based on formal notions of refinement, 
even supported with guidance given by constructive rules (see for instance [11]). 

With UML, we have employed a powerful and widely used modeling language to 
demonstrate the benefits of our approach. Our approach has the potential to support the 
integration of flexible communication regimes beyond broadcasting into arbitrary soft- 
ware architecture descriptions. Incorporating this support as a general design principle 
into corresponding case tools is a necessary and promising area of further development 
of our approach. 
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Abstract. Today’s manufacturing industry demands flexible and de- 
centralized production control systems to avoid hours of down time of 
the production line in case of a failure of a single central production con- 
trol computer or program. Additionally, today’s market forces demand 
smaller lot sizes and a more flexible mixture of different products manu- 
factured in parallel on one production line. These requirements increase 
the complexity of the control software. Consequently, sophisticated tech- 
niques for the development of such production systems are needed. In this 
paper we present an overview of our seamless methodology for integrated 
design, analysis, and validation for such production control systems. We 
illustrate our approach by an existing material flow system which is a 
major part of a real production system. We show how our modelling ap- 
proach is used for simulation facilities, code generation for programmable 
logic controllers, and maintenance purposes. 



1 Introduction 

Current production control systems for any complex industrial good, e.g. a fac- 
tory for cars, face two major problems. First, production control systems need to 
become more decentralized to increase their availability. It is no longer accept- 
able that a failure of a single central production control computer or program 
causes hours of down time for the whole production line. Second, today’s market 
forces demand smaller lot sizes and a more flexible mixture of different prod- 
ucts manufactured in parallel on one production line. These requirements result 
in highly complex systems, especially concerning the control software. Conse- 
quently, sophisticated techniques to develop such kind of production systems 
are needed. 



H. Ehrig et al. (Eds.): INT 2004, LNCS 3147, pp. 48-68, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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The ISILEIT project aims at the development of a seamless methodology for 
the integrated design, analysis, and validation of distributed production control 
systems. Its particular emphasis lies on (re-)using existing techniques, which 
are used by engineers in industry, and improving them with respect to formal 
analysis, simulation, and automatic code generation. The methodology defined 
in the ISILEIT project consists of several consecutive design steps covering all 
aspects of software and system design. 

At the beginning of every system design process a system specification de- 
scribing the functionality of the system has to be developed. In our case, the 
engineer uses an intelligent configuration system for the layout of the production 
system. For the early detection of faults in planning, the configuration system 
employs rules running in the background. Thus, specification errors are recog- 
nized very early in the development process and are eliminated immediately. 

The configuration of a production system also requires a specification of the 
functional requirements for the control software. This specification is done by 
using a graphical language which integrates SDL block diagrams, UML class 
diagrams, and UML behaviour diagrams like collaboration diagrams, activity 
diagrams, and statecharts in a visual specification (or even programming) lan- 
guage. This language is also considered to be a programming language because 
the code generation algorithm which has been developed within the ISILEIT 
project produces a complete executable version of the control software of a pro- 
duction control system. 

Generally, generating code from UML behaviour diagrams is not well under- 
stood. Frequently, the semantics of a UML behaviour diagram depends on the 
topic and the aspect that is modelled and on the designer that created it. In 
addition, UML behaviour diagrams usually model only example scenarios and 
do not describe all possible cases and possible exceptions. To overcome these 
problems we restrict the UML notation to a subset of the language that has a 
precise semantics. In addition, we define which kind of diagram should be used 
for which purpose and how the different kinds of diagrams are integrated to a 
consistent overall view. This precise semantics allows the automatic translation 
of the integrated diagrams to object-oriented programming languages like Java 
and C++ or even non-object-oriented languages for PLCs (Programmable Logic 
Controllers), which are widely used in the production industry. In this paper we 
present the PLC code generation for a material flow system used within our 
ISILEIT case study. 

One of the main problems in today’s manufacturing industry is long down 
times of production lines due to long testing phases of newly installed software. 
Our approach allows to validate the control software and to simulate the pro- 
duction process beforehand in order to shorten software reconfiguration down 
times of physical assembly lines. The validation and simulation is based on the 
generation of an executable model using the system design model. The gener- 
ated executable model is pure Java code, which can be compiled and executed 
on any computer platform supporting Java. It is used to simulate the system 
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and allows observing and visualizing the resulting system behaviour within a 
Virtual Reality (VR) application. 

Finally, when the manufacturing system is built up and the software is run- 
ning on the PLCs, an Augmented Reality (AR) tool is used. It augments the 
engineer’s field of view with different states of the manufacturing system, i.e. the 
user sees the real (physical) manufacturing system plus the digital augmented 
state information. The states displayed refer to the different components of the 
system. This includes all components of the production system as developed 
by the different domains, namely mechanics, pneumatics, electrics and even the 
software. As every component state is perceived, the engineer is able to see all de- 
pendencies between state changes of the different components during operation 
of the physical system. Such an AR tool provides benefits like online debugging, 
training, and better maintenance facilities. In the end it leads to a better overall 
understanding of the system and supports communication between the engineers 
from the different domains. 

The paper is organized as follows. The next section discusses related work 
in more detail. In section 3 the used case study is described. The defined seam- 
less methodology is addressed in section 4 where the different design phases 
are described as well. In section 5 the code generation for programmable logic 
controllers is presented. Our integrated tool support with simulation facilities is 
introduced in section 6. The following section 7 shows how augmented reality 
technology is used for the maintenance of the running system. In the last section 
the paper is concluded. 

2 Related Work 

Current approaches for the specification of production agents use either SDL [16] 
or statecharts [11]. SDL is very popular in the electrical and mechanical engi- 
neering community. SDL block diagrams are used to specify processes and chan- 
nels between such processes as well as messages passed via these channels. The 
behaviour of embedded system processes is specified using either SDL process 
diagrams or statecharts. Both notations basically model finite state automata 
which react on signals by executing actions, sending signals, and changing to new 
states. Both languages have a well defined formal semantics and tool support for 
analysis, simulation, and code generation [1, 6, 12, 14, 23, 26]. 

Compared to SDL process diagrams, statecharts provide more expressive 
language features like nested states, and-states, and history-states. In addition, 
the modelling of the internal process behaviour becomes the domain of software 
developers (instead of mechanical or electrical engineers) who are more used to 
statecharts than to SDL process diagrams. Thus, we decided to adopt statecharts 
for the purpose of modelling internal process behaviour. 

However, statecharts (as well as SDL process diagrams) lack appropriate 
means for the specification of the actual actions triggered by the received sig- 
nals. Usually, one has to use pseudocode for this purpose and in case of code 
generation one actually deals with the nasty details of current textual program- 
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ming languages. Statecharts provide sophisticated means for the specification of 
(concurrent) control flows for reactive objects. However, a statecharts purpose 
is to abstract from the complex application-specific object structures that make 
up the concrete states of a system. Statecharts do not explicitly deal with the 
values of attributes or links to other objects nor with the evolution and changes 
of these object structures caused by the execution of usual methods. 

The specification of application-specific object structures is a well-known 
application area for graph grammars, cf. [24, 25]. Basically, a graph rewrite 
rule allows the specification of changes to complex object structures by a pair 
of before and after snapshots. The before snapshot specifies which part of the 
object structure should be changed and the after snapshot specifies how it should 
look afterwards, without caring how these changes are achieved. While graph 
grammars are appropriate for the specification of object structure modifications, 
they lack appropriate means for the specification of control flows. Even the 
well-known graph rewrite system Progres [25] provides only textual control 
structures. 

To overcome this problem, in previous work we introduced UML activity di- 
agrams as high-level control flow notation for graph rewrite rules, cf. [9, 17]. For 
the specification of the reactive behaviour of communicating and collaborating 
production agents we integrated graph grammars, “hiding” them behind a col- 
laboration diagram notation to avoid acceptance problems within industry [20] . 



3 Case Study: A Flexible Production System 

The case study regarded in the ISILEIT project concerns a flexible and au- 
tonomous production control system for automated manufacturing. The pro- 
duction system depicted in Figure 1 consists of several NC controlled processing 
machines, robots, and manual work places which are connected by a rail-bound 
material flow system. The substantial components of this modular system are 
self-propelled transportation units 1 , switches 2 , and fixing stations, as well as 
straight and curved monorail tracks. 

Note that in our case study rail-bound shuttles for the transportation tasks 
are employed. In contrast to that, in the reference case study production au- 
tomation free-ranging Automatic Guided Vehicles (AGV) are used. However, 
this does not have any impact on our defined methodology for the integrated de- 
sign of such systems. Thus, our seamless methodology is also applicable without 
any restrictions for the reference case study. 

The experimental setup made in the mechanical laboratory for computer 
integrated production implements a manufacturing system for the production of 
bottle openers. The system consists of four stations which are connected by a 
material flow system. Figure 2 shows a schematic overview of our case study. 

A shuttle is electrically propelled and moves in exactly one direction. It ro- 
tates on the main loop until the control assigns a production task to it. If a 

1 called shuttles in the following 

2 called transfer gate in the following 
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Fig. 1. Flexible production system and its components 




MP I - Multi Point Interface 
PLC - Programmable Logic Controller 



Fig. 2. Schematic overview of our case study 



task was assigned to a shuttle, the first step is to move to the manual work 
place (station 1) where the production starts. There, the shuttle is equipped by 
a worker with the appropriate material. A touch panel with a display shows the 
worker which pieces are needed. After the shuttle is completely equipped the 
worker pushes a button to signal the material flow system to proceed. Now the 
shuttle moves to the portal robot (station 2) where the actual assembly takes 
place. The portal robot takes the material from the shuttle and hands it over 
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Fig. 3. Curve monitoring for collision avoidance 



to the rotator, where the required manufacturing step is performed. After that, 
the portal robot takes the assembled good from the rotator and puts it on the 
waiting shuttle. The shuttle now moves to the integrated buffer storage (station 
4) where it is unloaded by a SCARA 3 robot. Within this buffer, goods, parts, 
and materials are stored temporarily to ensure a continuous supply of necessary 
components. If the control does not assign a new task to the shuttle, it will rotate 
on the main loop until it gets one. Note that, for the moment, station 3 has no 
task within the current manufacturing process. However, in the near future it 
will connect this manufacturing system to a second one. 

The decentralized production control system consists of PCs on the supervi- 
sory control level and Programmable Logic Controllers (PLC) on the cell level. 
The actuators and sensors are connected to the PLC via an Actuator Sensor 
Interface (ASI). The communication among PCs and PLCs is implemented by 
a multi-point interface (MPI, Siemens AG). Higher-level tasks, e.g. planning, 
order assignment, and coordination of local activities of all controllers are done 
at the supervisory control level. The PLCs on the cell level are responsible for 
the control of local components such as stations or robots. 

Shuttles 

Shuttles are equipped with an opto-electronic distance sensor to prevent rear- 
end collisions with other shuttles. However, the range noticed by the sensor 
is reduced laterally in order to prevent unintentional stoppage of a shuttle by 
objects residing near the track. This leads to the fact that collision avoidance 
does not work properly within curves. 

To prevent rear-end collisions within curves the control has to ensure that 
only one shuttle enters a curve. This is achieved by the employment of additional 
sensor and actuator technology (cf. Figure 3). If a shuttle enters a curve the 

3 Selective Compliance Assembly Robot Arm 
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shuttle is detected by a proximity sensor. The control stops all following shuttles 
by activating a start/stop actuator. This blockage is released only if a passage 
sensor at the end of the curve announces a shuttle leaving the curve area. In 
our case study the sensors and start/stop actuators of stations are reused for 
the monitoring of these critical sections. For example, the presence sensors of 
station 3 and station 4 serve as curve entrance sensors, while the presence sensor 
of the station 1 acts as curve passage sensor. 

Stations 

All stations are built-up according to the same principle. Before a shuttle enters 
a station the speed of the shuttle is reduced. Each station provides a start/stop 
unit which consists of a stop pin and a starting actuator. The stop pin ensures 
that shuttles are stopped. The presence of a shuttle is announced to the control 
by an inductive proximity sensor. Before any processing starts, the shuttle is 
fixed by a pressure-controlled mechanical interlock. This is done for a precise 
positioning of the shuttle. The interlock has to be released before the shuttle is 
started by the starting actuator. 

Transfer Gates 

Within our material flow system two types of transfer gates can be identified: 
those that branch out of a track (Brancher) and those that merge two tracks into 
one (Joiner). Although they are used differently, they are identical in construc- 
tion and operate on the same principle. Figure 4 shows a schematic overview of 
a transfer gate. 

A transfer gate con- 
sists of an interlock, a 
double-action pneumatic 
cylinder, and two prox- 
imity sensors, one for 
each switching direction. 

For safety reasons the 
transfer gate is generally 
locked. The first step for 
switching into another di- 
rection is to disengage 
the interlock by activat- 
ing the singleaction pneu- 
matic cylinder. Now the 
transfer gate can change 
its direction by turning Fig. 4- Trans f er Gate 

into the new position. 

This is done by the double-action pneumatic cylinder. When the switching oper- 
ation is completed, the final position is detected by one of the proximity sensors. 
After that, the pressure-controlled mechanical interlock has to be re-engaged. 
The occurrence of a switching failure can be recognized only by an absent sensor 
trigger after a predefined timeout. Additionally, before starting the switching 
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process, the control has to guarantee that no shuttles are located on or are en- 
tering the transfer gate. This is achieved analogous to the curve monitoring for 
collision avoidance described previously. 



4 Modelling Approach 

In this section we give a brief overview about our modelling approach. A more 
detailed description can be found in [20] and a graphical overview on our software 
development process in [22], The software development process for the above 
mentioned case study is defined by six phases: 



Analysis Consolidation Phase. Based on the results of a previous informal 
requirements- gathering phase which is beyond the scope of this paper, in this 
phase the topology of the planned production control system is modelled. This 
includes the identification of the number and types of participating processes as 
well as the definition of communication channels and of all kinds of interchanged 
signals. 

We use SDL block diagrams for this purpose since SDL block diagrams are 
very popular in engineering disciplines and this work is done in close collabo- 
ration with mechanical and electrical engineers. However, many of the missing 
concepts for large- scale and complex system development have been integrated 
into the UML 2.0 proposal of the main tool vendors [21]. Hence, they are likely 
to become a part of the standard UML and will therefore be widely available in 
the industry. Thus, in the near future SDL specifications may become obsolete 
and be replaced by the new UML 2.0 standard for the same purpose. 



Design Phase. In the next step, one derives the initial (UML) class diagram of 
the desired system. Here, each process(type) identified in the SDL block diagram 
generates a class in the class diagram. In addition, each signal received by a 
process in an SDL block diagram creates a signal method in the corresponding 
class. 



Reactive Behaviour Modelling Phase. SDL block diagrams (and the de- 
rived class diagrams) specify the particular signals which are provided and un- 
derstood by the different processes. Now we have to define how each process 
will react on these signals. Thus, for each process class, one has to provide a 
stateclrart describing the general process behaviour. These statecharts should at 
least cover all signals that are understood by / declared in the corresponding 
process class. 

In the engineering field, SDL process diagrams are usually used for this pur- 
pose. We chose statecharts due to their additional expressive power over SDL 
process diagrams provided by nested states and and-states. 
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Action Modelling Phase. Statecharts specify in which states a certain pro- 
cess reacts to a particular signal. In response to a signal, a process might change 
its state and execute some additional activities. For a flexible production agent, 
these activities might again include complex computations. These complex com- 
putations might employ or modify complex object-oriented data structures in 
order to reflect the surrounding world or the execution of manufacturing plans 
for certain products. For the specification of such complex computations we use 
UML-like collaboration diagrams with a precisely defined operational semantics 
based on graph-grammar theory [9]. Consequently, we use collaboration dia- 
grams to specify complex control flows of methods employed as actions within 
statecharts. 

Frequently, one will need more than a single collaboration diagram to model 
a number of object structure modifications. Therefore, we combine statecharts 
(and activity diagrams) with collaboration diagrams yielding a powerful visual 
specification language. Basically, we allow using collaboration diagrams as the 
specification of activities instead of just pseudocode statements. 



Verification. When the system design model, which will be used for code gen- 
eration, reaches a mature state it will be verified. This proves the correctness of 
the specified control software. The verification is done by formal model-checking 
techniques based on ASM and AsmL [22] . 

Code Generation Phase. Once all aspects of the system are specified, the 
Fujaba environment is able to generate a complete, executable Java implemen- 
tation from the class and behaviour diagrams. This implementation is further 
used for the simulation phase that follows. Furthermore, as will be explained 
later, generation for PLCs is also possible and supported. 



Simulation Phase. One of the main problems in today’s manufacturing in- 
dustry is long down times of assembly lines due to long testing phases of newly 
installed software. Our approach allows to simulate the production process be- 
forehand in order to shorten software reconfiguration down times of physical 
assembly lines. 



Maintenance Phase. Once the manufacturing system is built and operating, 
the maintenance phase starts. The aim is to provide an uninterruptible operating 
process. Causes for interruptions have to be analysed and eliminated as fast as 
possible. The analysis of causes for an interruption generates down time of the 
manufacturing system. An AR-tool will support this analysis and shorten down 
time of the manufacturing system. 

In our approach, the different diagrams are mutually dependent on each other. 
The SDL block diagrams specify the minimum number of (process) classes to 
be contained in the class diagram and for each such class all its signal meth- 
ods. In addition, each process class is equipped with one main statechart. This 
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statechart has to define the response to all signals of the corresponding class. 
In addition to state changes, this response might include actions. Each of these 
actions is specified using one behaviour diagram (which in turn may apply ad- 
ditional diagrams for sub-activities). Thus, following our seamless methodology, 
this leads to an overall specification where each aspect of the system is specified 
by exactly one diagram, e.g. an SDL block diagram defining the overall archi- 
tectural view and possible communication channels between processes, a class 
diagram refining the architectural view, and a statechart-based refinement of 
all communication channels by defining exactly one statechart for each process. 
A complete syntactic definition of all used diagrams, including static seman- 
tics which supports inter-diagram consistency analysis, is explained in [5, 27]. 
A semantic model integrating all used diagrams is given in [22]. Note that our 
integrated approach allows an arbitrary number of loops between the different 
phases. Hence, the incremental development is supported by the corresponding 
environment. 

This section presented a brief overview about the different phases of our mod- 
elling approach. For a detailed description of the first four phases see [18, 20], 
whereas the verification phase and the appropriate semantic integration are pre- 
sented in [22]. In the following sections we focus on the last three phases starting 
with a more detailed description of the code generation for programmable logic 
controllers. 



5 Code-Generation for PLCs 

Control systems are often complex, safety-critical and expensive. Any failure in 
the control software might not only result in a financial loss but lead to accidents 
as well. Therefore, in our methodology we employ validation via simulation and 
formal verification of the modelled system. After a successful validation and 
verification, the entire system model needs to be implemented. One way to ensure 
a correct translation of the model into a program is to generate the code from 
the model automatically. 

In our approach, the defined precise semantics of the used models allows the 
automatic translation of the integrated diagrams into object-oriented program- 
ming languages like Java and C++ [20]. The generated executable code is used 
for the simulation phase (cf. section 6) and the supervisory control at a higher 
control level as well. However, in our case study, we use Programmable Logic 
Controllers (PLC) to execute the control software on the cell level. 



5.1 Programmable Logic Controllers 

Programmable Logic Controllers (PLC) are microprocessor systems that are 
widely used in industrial automation. The reason for their popularity in this field 
is that they are robust and reliable. A PLC is connected to sensors and actuators: 
the former provide information on the state of the controlled production system 
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while the latter perform the actions prescribed by the control software. Hence, 
the basic task of the software is to map input information into output commands. 

PLCs behave in a cyclic manner where each cycle follows three phases: (1) 
poll all inputs and store read values, (2) compute new output values, and (3) 
update all outputs. The repeated execution of this cycle is managed by the 
built-in real-time operating system. Thus, the programmer has to adapt only 
the computing phase for the output values. 

For the decentralized control of our manufacturing system we use four PLCs 
of type Simatic S7-300. The controller uses the actuator sensor interface for a 
continuous interaction with the environment and reacts to events stimulated by 
the environment in a negligibly short time. Thus, the controller can be seen as 
a reactive system [13]. For the modelling of reactive behaviour, stateclrarts [11] 
are used and have to be implemented on the target platform. In the following 
we give a short impression on the translation of a statechart to Structured Text 
(ST) for programmable logic controllers by means of an example. Note that the 
code generation for our UML-like collaboration diagrams employed as actions 
and activities within stateclrarts (cf. section 4) was already presented in our 
previous work [20]. 

5.2 Implementing Statecharts 

There are different programming languages for PLCs, each intended for a spe- 
cific application domain and based on the background of the control engineer 
who uses them. In order to achieve more conformity of the different notations 
the standard IEC 61131- 3 [15] was developed. Each of the standardized lan- 
guages cover different abstraction levels. Instruction List (IL) for example is a 
low level assembly language very close to hardware programming, whereas Se- 
quential Function Charts (SFC) describe the sequence of a PLC program as a 
state transition diagram. For the automatic generation of PLC-code, we adapted 
the code generation mechanisms to produce Structured Text (ST) instead of Java 
code. Structured Text is a notation similar to PASCAL. It is a higher level lan- 
guage than IL and provides more structuring and organizing constructs such 
as if-then-else-conditionals and while- loops. However, as a classical procedural 
programming language, ST does not support typical object-oriented concepts 
like inheritance or polymorphism. Thus, a direct mapping of a statechart to 
an object-oriented implementation, e.g. the state-pattern [14, 10], is not pos- 
sible. The mapping of object-oriented concepts has to be managed explicitly 
as described in [20]. For statecharts, we omit this overhead by using a simpler 
translation based on switch-case statements [4, 23]. 

Figure 5 depicts a simple statechart of the control software for the transfer 
gate used in our case study (cf. section 3). The specified statechart switches 
the transfer gate between the straight and the round direction. Initially, the 
transfer gate is switched to the straight direction and fixed by a mechanical 
interlock. When the round() event is received, the interlock is disengaged by 
the exit action lock:=false, and state straight unlocked is entered. After that, 
the triggerless transition is fired and the appropriate action valve^def:=false is 
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Fig. 5. Statechart of the transfer gate controller 

executed. This action triggers a pneumatic cylinder responsible for turning the 
transfer gate into the round direction. The state switching round is left either 
if the proximity sensor announces that the switching process completed or if a 
timeout of 2000 milliseconds occurs. In the case of a timeout, a failure state is 
entered. In the other case, the switching process was successful. Thus, state round 
is entered and the interlock re-engaged. Now the transfer gate can be switched 
back to the straight direction by sending a straight() event. The switching is 
performed analogous to the described switching process for the round direction. 

When implementing a statechart on PLCs, two problems arise. First, there is 
a problem moving from an event-based statechart world into a signal-based PLC- 
universe. In contrast to events, signals exist the whole time and are handled by 
the PLC as boolean values. To overcome this problem, an event can be associated 
with the rising and falling edges of a corresponding signal. For example, a rising 
edge can be detected comparing the signal between two cycles. If the signal was 
low in the previous cycle and is now high, a rising edge is detected [7]. 

Second, due to the cyclic execution of the three phases, signals and events 
from the environment can appear to occur simultaneously. Even worse, if a signal 
does not hold for at least the maximum amount of time needed for a cycle, one 
cannot be sure that the PLC will ever read the signal. The solution to this 
problem is to use PLCs which are fast enough. 

In our experimental case study the used PLCs run infinitely faster than the 
environment. Hence, signals are always recognized and do not occur simultane- 
ously. The control system can be seen as a reactive system with a negligibly 
short reaction time to signals and events stimulated by the environment. Hence, 
the assumption of the perfect synchrony hypothesis [3] regarding the interaction 
between the environment and the controller on the cell level is fulfilled. Note 
that, as mentioned in section 4, this is not true for the decentralized case with 
a large number of asynchronous communicating control units. This case is still 
handled as described in [20]. 

The behaviour of a statechart can be implemented by simple switch-case 
constructs. The piece of code in Figure 6 is part of the generated program for 
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VAR state: INT 1; /* state - "straight" */' 

timer: TIMER; 
expired: BOOT :— FALSE; 

END_VAR; 

CASE state OF 



3:/* state = "switching round” */ 
timer ( T.N :=TRUF., TV: =T#2000ms) ;/* start or update ti mer */ 
expired :— NOT timer. Q; /* test for expired timer */ 



IF (rou:id_se:isor — TRUE) THEN / *when (round_3ensor — true) */ 
t.i.mer (IN :=FAT SF., TV:=T#?000ms) ; /* stop timer */ 
state := 4; /* state = "round." */ 

.Lock := TRUE; /* entry action */ 



ELSIF (expired - TRUE) THEN /* after 2000 */ 

timer (IN: -FALSE, TV : -T# 2 000ms ) ; / * stop timer */ 
state :- 7; /* state - "failure" */ 

END IF; 



4:/* state = "round" */ 

T.F (straight = TRUE) THEN 
lock := FALSE; 
state := 5; 

END IF; 



event.: straight 0 */ 

exit, action */ 

state = "round unlocked" */ 



END CASE ; 



Fig. 6. Example for generated PLC code 

the stateclrart shown in Figure 5. It gives a short impression on the translation 
in Structured Text for the states switching round and round. 

We declare an integer variable state to keep the current state of the state- 
chart. Each state is encoded by an integer which is handled in a case statement. 
Events and signals are translated to boolean variables in the symbol table. The 
symbol table provides a mapping between the program and the sensors /actuators 
plugged in to the PLC. In each state, the outgoing transitions of that state are 
treated. Timer events are handled by built in timer functions. If a transition 
is enabled, the new state is set and the appropriate exit and entry actions are 
executed. Note that the presented program is executed once in each cycle. Thus, 
it is the body of an implicit loop- forever statement. 



6 Tool Support: An Engineer’s Workstation 

The engineer’s workstation is based on the integrated environment Fujaba [5] 
including tools which support software specification as explained in the previous 
sections. Figure 7 gives an overview of the employed tools. 




An Engineer’s Workstation to Support Integrated Development 



61 



SDL block diagrams 



F(/3 ABA 




collaboration diagrams 
with graph-grammar semantics 



Fig. 7. Engineer’s workstation based on the Fujaba Tool Suite integration platform 



Fujaba includes editors for SDL block diagrams, UML class diagrams, stat- 
echarts and story diagrams as well as tools for code generation and formal verifi- 
cation [18]. In addition, the consolidation phase (cf. section 4) is supported by a 
configuration tool called Projector. This tool supports the engineer developing 
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the topology of the manufacturing system including sensors and actuators. The 
engineer configures the system by taking components from a graphical library. 
With the graphical interactive user interface he positions, orient, and connects 
the hardware components. Examples of components are straight tracks, curve 
tracks, transfer gates, and stations. The engineer also configures the actuators 
and sensors. Actuators and sensors are a part of the system specification. To en- 
sure the consistency of the topology, rules are executed in the background while 
configuring its components. These rules detect several configuration faults and 
correct them automatically. This helps to avoid design faults in the early stages. 
Projector is a commercial tool that is developed by the FASTEC GmbH [8]. 

The configuration tool is based on a library of predefined components, i.e. 
software models of the real physical devices. These models specify the behaviour 
of the corresponding physical components using statecharts, UML-like collabora- 
tion diagrams with graph grammar semantics, and activity diagrams. The com- 
bination of collaboration and activity diagrams to story diagrams is described 
in [9, 28], 

As an example, the specification of one library component, namely a transfer 
gate, is described in more detail. In Figure 8 the transfer gate component is 
specified as a class with boolean attributes representing actuators and sensors. 
Note that later on these attributes will be accessed by the control software. 
The behaviour of the component is described by a statechart and depends on 
the values of the actuator attributes. In the given example, there are states for 
each switching direction ( round , straight ) of the transfer gate (cf. section 3). 
The switching direction and thus the state of the transfer gate changes if the 
valve attribute is changed and the interlock attribute is not set. This behaviour 
describes the real transfer gate with the interlock disengaged and the double- 
action pneumatic cylinder starting to change the direction. For example, if the 
transfer gate is in state straight , the valve true , and the interlock false, then state 
round is entered and the entry action round() is executed. Entry actions are 
specified by story diagrams in order to change object structures and attributes. 
The action specified by the story diagram round() destroys the link to the object 
straight.Track and creates a link to the object roundTrack. After that the sensors 
for the directions are set accordingly. This completes the switching process. 

The combination of the previously described library components, the topol- 
ogy and the specified control software allows the entire system to be simulated. 
Based on this specification, executable code is generated, i.e. the control code 
and the code that represents the behaviour of the physical system. In contrast 
to other tools and simulation environments, the simulation model is not inter- 
preted, but executed. The generated code implies the simulation model and its 
execution simulates the entire system. 

This simulation model is connected to a 3D model that is rendered in real- 
time using Virtual Reality (VR) technology. The 3D model is based on the 
topology of the manufacturing system and its object model and it is generated 
automatically. The animations in the VR environment, e.g. moving shuttle or 
switching transfer gate, are triggered by the executed code. This means the 
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Fig. 8. Software models describing one library component (Joiner) 



simulated states of components of the manufacturing system can be visualised. 
This 3D model is examined using the advantages of immersion and the human 
machine interaction that is delivered by VR while the simulation is running. A 
screenshot is shown in Figure 9. It shows an extended 3D model of the complete 
case study. 
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Fig. 9. 3D model of the case study 



7 Maintenance and Ramp-Up 

The process to build a manufacturing system and put it into operation is called 
rampup. When the manufacturing system is built and the software is running on 
the PLCs there can be two types of faults that may interrupt the manufactur- 
ing process. The software may be incorrect 4 or hardware components could be 
broken or not installed properly. The interruption may occur later on when the 
ramp-up process is finished and the system is running. To support the so-called 
ramp-up process and the maintenance of the manufacturing system an AR-tool 
is used to enable fault detection and cause analysis. In the following, the AR 
technology is introduced and the application of AR in the ISILEIT project is 
described. 

Augmented Reality is a new form of man-machine interface which is closely 
related to VR [2], In Augmented Reality the computer provides additional in- 
formation that enhances or augments the real world. The user can interact with 
the real world in a natural way, with the AR-system providing information and 
assistance. Therefore, AR enhances reality by superimposing information rather 
then completely replacing it, like VR (Virtual Reality) does. The information 
is inserted in a context-dependent way, i.e. derived appropriately from the per- 
ceived real world object. A real world object is recognised and, depending on 

4 Due to the complexity of the regarded system, verification is performed for safety- 
critical software components only. Hence, the software may still contain undetected 
faults and defects. 
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the specific object, the content-dependent information will be retrieved and dis- 
played. The motivation is that Augmented Reality enhances a user’s perception 
of and interaction with the real world. The virtual objects display information 
that the user cannot directly detect with his own senses, e.g. states of sensors or 
software. The information conveyed by the virtual objects helps a user perform 
realworld tasks [19]. 

The man-machine interface AR in ISILEIT supports the integration of the 
different domains. Connecting the AR tool and the controllers will enable the 
system to retrieve state information. The states refer to the different components 
of the system. This includes all components of the manufacturing system as 
developed by the different domains, namely mechanics, pneumatics, electronics 
and even the software. 

Most states and changes will be seen in reality, e.g. the switching of a trans- 
fer gate. The state of a sensor may be indicated by the glow of an LED or a 
pneumatic cylinder may cause a motion activity. But these real components can 
be hidden, e.g. the cylinder is integrated into the transfer gate. The user perhaps 
doesn’t know the actuator’s position and how it works within the transfer gate. 
Using the AR tool the cylinder can be displayed as a 3D-object with the active 
state at a position within the transfer gate. The state change of the actuator can 
be shown by using a 3D animation. Regarding the realtime aspect, the virtual 
actuator will change its state while the transfer gate is switching from one to 
another direction. 

In opposition to states that refer to real components, the states referring to 
electronics and software are not directly perceptible. These states can only be 
visualised with the real system and the AR tool. The internal computer model 
receives the software specification from the integration platform. An interface to 
the PLCs enables the AR tool to retrieve the I/O values of the PLC’s ports. This 
allows the abstract software states to be combined, e.g. statecharts or object dia- 
grams, and the corresponding signals sent or received by the PLC. Dependencies 
between hardware and software are now identified without reading the control 
code, but by looking at the real system and receiving augmented information 
about the states of the system. As every component state is either seen in re- 
ality or can be displayed virtually, the engineer is able to see all dependencies 
between state changes of the different components during operation of the physi- 
cal system. The described AR tool provides benefits like online debugging, better 
maintenance, and training. In the end it leads to a better overall understand- 
ing of the system and supports communication between engineers from different 
domains. 

In the case of an error the AR tool is used for failure detection. The failure 
detection is based on the analysis of the dependencies and impacts between lrard- 
and software. By using the AR tool it is possible to explicate states and state 
changes of mechanics, pneumatics, electronics, and the software. 

The regarded component for the above-referenced application scenarios is the 
transfer gate and the corresponding statechart describing the control software 
shown in Figure 4 and Figure 5. In this scenario, for instance, one of the inductive 
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proximity sensors is not working correctly. Sometimes it does not detect that the 
final switching position of the transfer gate has been reached. The result is that 
the interlock is not re-engaged and the switching process is not finished. No shut- 
tles should now be allowed to pass through this transfer gate. The engineer sees 
that the transfer gates switches but he can not perceive whether the interlock, 
the inductive proximity sensor, or the software is causing the problem. In par- 
ticular, if the inductive proximity sensor fails in only some cases, the reason for 
the failure is hard to find. Using the AR tool, the engineer can retrieve all states 
online in real-time. The moment the failure occurs, current states are displayed. 
The stateclrart seen in Figure 5 will show him that the current state is switching 
round and the condition is when (roundsensor = =true) to change into the next 
state round that will re-engage the interlock on entry. The software will switch 
to the state failure after the timeout of 2000 milliseconds. The transfer gate has 
switched as seen in reality, but the inductive proximity sensor does not detect 
the final switching position. Hence, the state is not changed. This information 
is displayed as augmentation in the view of the engineer, i.e. the state of the 
sensor is shown at its real position. Combining all the given states the engineer 
infers that either the sensor or the wiring causes the fault. After he verifies that 
the wiring has no slack joint, the conclusion is that the sensor is the cause for 
the failure and has to be replaced. 

Additional benefits of the AR tool are a better overall understanding and 
integrating the views of the different domains (literally), e.g. understanding the 
interrelationship between software, sensors/actuators, and hardware. Regarding 
the transfer gate as described before, the disadvantage of the built-in switching 
actuator and the interlock is that they can not be seen while standing in front of 
the transfer gate. For training and educational purpose this might be explained 
with the AR tool. The transfer gate is seen in reality. The built-in components 
like the interlock and the switch actuator are displayed as 3D objects (pneu- 
matic cylinders) at their real position. The user can change position or walk 
around the transfer gate, if possible, and the 3D objects will remain where their 
corresponding real counterpart is built-in. The state of the cylinder (extended 
or not extended) is directly visible. The change of the state is visualised by an 
animation of the 3D object. Additionally, the states of the other sensors and 
the software can be used to augment the field of view. All this information, 
states, and supporting 3D graphics can be taken to develop a didactical guiding 
AR.-system that explains the functionality of the manufacturing system and the 
interrelationship between the components during operation. 



8 Summary 

In this paper we presented an overview of our seamless methodology for the in- 
tegrated design, analysis, validation, and verification of production control sys- 
tems. The paper focused on code generation for programmable logic controllers, 
simulation and maintenance. We developed a code generator for implementing 
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statecharts on PLCs. The presented translation of stateclrarts is based on simple 
switch-case constructs in the programming language Structured Text. 

Due to demanded flexibility in shorter innovation cycles, today’s manufactur- 
ing industry needs shortened phases for development and ramp-up of the control 
software. In this paper we presented an approach to simulate the software before- 
hand. While the simulation is running, faults in the control software are detected 
by the engineer early in the design phase. Thus, faults in the control software 
are corrected even before the manufacturing system is built. This significantly 
reduces the time needed for the final system tests on the real hardware. 

Furthermore, we have shown how we incorporated Augmented Reality tech- 
nology for maintenance of the operating manufacturing system. 

The concepts described in this paper were integrated in a tool integration 
platform called Fujaba Tool Suite. This platform is the basis for the engineer’s 
workstation and supports the described phases of our modelling approach. The 
release of Fujaba is available via: http://www.fujaba.de 
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Abstract. Motivated by the wide acceptance of component based tech- 
nologies in software development, a component concept for software en- 
gineering is applied to modeling in the held of production automation. 
Taking the modeling of a holonic transport system as an example, it is 
shown, how function blocks in the sense of production automation can 
be understood as software engineering components. Thus, the advantages 
of component based modeling with respect to structuring, exchange and 
reuse can be transferred to systems in production automation. 



1 Introduction 

Component based technologies for the development of complex software sys- 
tems, e.g. Java Beans and Corba, found a wide acceptance in todays applied 
software engineering. These technologies ease the development of large scaled 
software architectures since the abstraction of the realization of the funcionali- 
ties to component interfaces minimizes the complexity of architecture building. 

In using so called “middleware” it is tried to gain a certain independence 
of concrete programming languages for the component implementations. But 
also physical devices with corresponding interfaces can be understood as com- 
ponents, and hence, whole production systems can be described as component 
architectures. 

Not only the improved handling of the structuring of systems, which primary 
leads to a reduction of the complexity in the design stage, but also reusability 
and exchangeability are regarded as important advantages of component based 
technologies. If a component is implemented once, it is possible to use the same 
component implementation for another project, if the functionality of the com- 
ponent is, maybe partially, relevant for the new project. This means, the new 
environment of the component imports functionalities, which are offered by the 
component. Therefore the services, the component expects from its environment, 
have to be available in the new context. Moreover, components can be replaced 
within a single system. In this case, the new component has to fulfill the as- 
sumptions of the existing system. 

In addition, component structures ease the adaption of software systems to 
changed requirements and environment condidtions, since the system adaption 
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might eventually be limited to single components. If the changed components 
fulfill their interfaces afterwards, the remaining system components can be left 
unchanged without any further examiniation. 

In order to specify system components before the actual implementation, a 
suiting component based specification technique is needed. Existing techniques, 
especially the UML components in [1], lack a means to express abstract inter- 
face specifications. The components in the new UML 2.0 specification in [2] are 
already a lot more elaborated and have notions of explicit export and import 
interfaces. Unfortunately, the UML diagram element for an interface still has 
some restrictions that seem to be inappropriate for a usage in our application 
field (e. g. it is not intended to instantiate interfaces, which stands in conflict to 
the ideas presented in Sect. 4). For this reason we will still use a special kind of 
UML subsystems in this paper, which were developed in [3] to integrate function 
blocks in the sense of production automation into an object oriented method for 
the development of prodution systems presented in [4] . 

These subsystems are an instance of the abstract component concept pre- 
sented in [5]. In this approach a component is defined by three specification 
parts: export, import, and body specification. The export specification describes, 
which services the component offers to its environment. The body specification 
describes the realization of the exported service using the imported services of 
the component. This approach carries the advantages of component based tech- 
nologies, i.e. abstraction, reusablility, and exchangeability, to the design stage 
of the development process. 

For several reasons, it is desirable to have specification techniques available, 
that are equipped with a formally defined semantics, because this enables the 
(partial) code generation of implementations for the software part of the system. 
Beyond this, a formal semantics provides additional advantages. The semantics 
and correctness of a composed system can e. g. be deferred from the semantics 
and correctness of its components, provided that the used composition operations 
are compatible with the semantics. In this paper we will use a specification 
technique consisting of UML class diagrams and UML stateclrarts as in [1] and 
a simple action language based on the notations of OCL. For a number of UML 
techniques a formal semantics based on transformation systems was developed 
in [6,7], which have been summarized and integrated in [8]. 

In [9] we have already presented first ideas concerning the correspondence 
of function blocks according to [10] and software specification components. In 
contrast to [9] we will give a much more detailed discussion in this paper and 
we show how the used component framework can be extended by a model based 
semantics. 

The paper is organized as follows: In Sec. 2 we show how function blocks 
in production automation can be modelled using diagram techniques from the 
UML. In Sec. 3 we interpret these UML function blocks as components in a 
formal component concept. In Sec. 4 we sketch a model-theoretic semantics for 
such components. Finally, in Sec. 5 we conclude by giving some directions of 
future work. 
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2 Modelling Function Blocks with UML Subsystems 

In this section we show how function blocks according to the IEC/PAS 61499- 
1 specified in [10] can be modelled by UML subsystems in the sense of [1], 
This approach, using the ODEMA 1 method presented in [4,11], was originally 
introduced in [3]. 

Figure 1 shows the characteristic elements of a simple function block ac- 
cording to IEC/PAS 61499. These elements are mapped to a UML subsystem 
function block in the following way: In the specification part of a UML function 
block we model the event and data flow of the services the subsystem offers to 
its environment (export interface), while distinguished (proxy) elements in the 
realization part model the event and data flow of services it assumes from its 
environment (import interface). The rest of the realization part models internal 
data, execution control and algorithms of the function block by a class diagram, 
statecharts and action language expressions. 



Instance Name 




Fig. 1 . Function block characterization 



The specifications of function blocks shown below are slighlty modified parts 
of a solution for the reference case study “holonic matererial flow” , presented in 
[12], within the DFG priority program “Software Specification” (see [13]). This 
solution was developed in the project IOSIP 2 and can be found under [14]. 

Figure 2 shows the function block structure of the control software of an 
H-AGV 3 , where function blocks are symbolized as UML subsystems. The func- 
tion block 10 reads out the incoming data stream from the CommunicationMedia. 
Data packages that have to be send to other H-AGVs are transferred through the 
10 function block, too. Hence, the function block CommunicationMedia, which is 
a function block realized by an apparat, has to offer features for receiving and 

1 Object-oriented method for developing technical multi-agent-systems 

2 Integration of object-oriented software specification techniques and their application- 
specific extension for industrial production systems on the example of automobile 
industry 

3 Holonic automated guided vehicle 
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sending data in its interface. The function block Interpreter analyzes incoming 
messages that are relevant for the particular H-AGV. If, for example, a machine 
status was received, a possibly necessary negotiation would be initiated. For this 
purpose, a calculation of costs and the composition of outgoing messages would 
be done in the Negotiatior function block. These messages would be put into 
the used communication protocol in the Mediator function block, before they 
reach the I/O function block. If the negotioation ends up with transport order, 
the controlled H-AGV has to drive to the particular workpiece. This happens 
under the usage of the DrivingControl function block, where the controlling of 
the driving relevant sensors and actuators in the function block Vehicle is im- 
plemented. The function block Handover realizes the loading and unloading of 
workpieces between H-AGVs and machines by a carrier apparat in the Carrier 
function block. 
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Fig. 2. Architecture of the H-AGV control software 



The function block Handover, shown in Fig. 3 uses the sensors and actuators 
of the workpiece carrier of the H-AGV. Thus, the function block has output 
events that are used as communication signals for the function block Carrier. 
The small boxes on the lines modeling the event and and data flow mark syn- 
chronization points. For example, the event loadWorkpiece is connected to two 
data elements, wpt and m of type WorkpieceType and MachinelD, respectively. 
The Return events are meant as signals that report the termination of a cor- 
responding method, where some of them are connected to data flow elements, 
which means that this method has a return value of that type. 




A Formal Component Concept for Industrial Control Systems 



73 



EVENT 

EVENT 

EVENT 

EVENT 



WorkpieceType 

MachinelD 

BOOL 



loadWorkpiece 

unloadWorkpiece 



ReturnJWp 

Return_uWp 

submitLoad 

submitUnload 

executeLoad 

executellnload 



□ □ 



wpt 


Handover 


return 

wpt 




m 




success 




m 



□ □ 



EVENT 

EVENT 

EVENT 

EVENT 

EVENT 

EVENT 



BOOL 

WorkpieceType 

MachinelD 



Fig. 3. Function block Handover 



This representation style might be very useful for realizing function blocks 
by physical devices, but if a function block is planned to be realized by a piece of 
software, it should be expressed in a modeling language which is more common in 
the software engineering world. We will use UML diagrams and the UML based 
method ODEMA for this purpose together with a mapping of function blocks 
to UML subsystems originally presented in [3]. Figure 4 shows the structure 
of the function block Handover and the function blocks it relies on to provide 
its funcionality, where the function block Carrier is realized by an apparat and 
the function block Mediator by a software component. This is represented in the 
diagram by corresponding UML components with the stereotypes <<embedded>> 
and «executable>>, respectively. 




Fig. 4. Subsystem structure of the function block Handover 
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In Fig. 5 it is shown, how the event and data flow structure of the function 
block HandoverControl can be respresented by UML classes. Since this func- 
tion block contains a single control component only, we can draw the class dia- 
gram directly into the subsystem frame. In general, function blocks can contain 
more than one control component. The export interface subsumes the meth- 
ods, the function block offers to its environment. We use asynchronous signal 
events which are declared in the inteface of the corresponding function block 
with a <<com>> stereotype for the communication with embedded subsystems. 
We use synchronous method calls for the communication between executable 
software subsystems. Moreover, the dependencies to other subsystems are redi- 
rected through interfaces marked with the stereotype «OD proxy » in order to 
make explicit the imports of the subsystem, which leads to a self-contained de- 
scription of the function block. 




) ExpHandoverControl 



«functionblock» 

Handover 




Fig. 5. Detailed structure of the single control component in the function block Han- 
dover 



In Fig. 6 we see the specification of the reactive behavior of the function 
block by a stateclrart. We can regard this as an addition to the export interface 
as well as the body of the function block specification. The stateclrart allows 
other functionblocks to call the method loadWorkpiece, whenever the carrier is 
empty, and the method unloadWorkpiece, if some workpiece is loaded onto the 
H-AGV. Both methods non-deterministically choose to either switch the state or 
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stay in the same state, since this choice depends on the success of the imported 
submit methods of ExpMediatorHandover, which are not visible in the stateclrart. 
Other function blocks importing Handover have to ensure, that this protocol is 
respected. 




Fig. 6. Statechart of the function block Handover 



The specification of the realization of the methods is encapsulated in the body 
specification of the function block. Figures 7 and 8 show such action language 
specifications for the methods loadWorkpiece and unloadWorkpiece, respectively, 
where we use a rather simple ad hoc action language, which is neither part 
of the UML nor ODEMA at the moment. The description shows the concrete 
sequence of actions and how other methods, e.g. submitLoad, and signals, e. g. 
executeLoad, are used in the method. 



context BodHandover::loadWorkpiece(wpt: WorkpieceType, m: MachinelD): 
if submitLoad(wpt, m) 
then executeLoad (wpt); 
set loaded := true; 
set loadType := wpt; 
return true 
else return false 
endif 



Fig. 7. Action language description of the method loadWorkpiece 



An addition to the import specification is the protocol statechart in Fig. 9, 
which constrains the signals executeLoad and executeUnload to be sendecl alter- 
nating. On the other hand the methods of ImpMediatorHandover are not further 
constrained. 

In the next section we will show, how function blocks modelled by UML 
subsystems as presented in this section can be interpreted as components in 
a formal specification component concept, and which benefits can be drawn 
from two kinds of semantics for these components. Especially we will see how 
architectures of function blocks can be flattened by a composition operation 
based on a transformation semantics for components. 
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context BodHandover::unloadWorkpiece(m: MachinelD): 
if submitUnload(loadType, m) 
then executellnload(loadType); 
set loaded := false; 
unset loadType; 
return true 
else return false 
endif 



Fig. 8. Action language description of the method unloadWorkpiece 



executeLoad(wpt) 




executeUnload(wpt) 

Fig. 9. Statechart of the import ImpCarrierControl 



3 UML Subsystems in an Abstract Component Concept 

In this section we shortly introduce an abstract component concept based on 
the ones published in [15] and [5]. Then we show, how UML subsystems can 
be interpreted as components in the sense of this concept and which semantical 
implications arise from such an interpretation. 

In contrast to software components such as the ones in CORBA, Java Enter- 
prise Edition or .NET, the component concept considered here is concerned with 
specification components, which are means to structure large specifications into 
manageable parts. The concept of specification components is orthogonal to the 
software components in the implementation and deployment structure, i. e. there 
is not necessarily a bijective correspondence between specification and software 
components, but there could also be specification components, which specify 
several software components, and, vice versa, software components, which are 
specified in several specification components. 

A component Comp in this framework consists of import and export interface 
specifications Imp and Exp and a body specification Bod, which is supposed to 
realize the provisions granted in Exp using the requirements stated in Imp. 
Note, that Imp, Exp and Bod are in general supposed to be constructed from 
the same specification techniques. Hence, the interfaces are not restricted to 
certain kinds of specifications, unless we explicitly impose such a restriction for 
an instantiation of the component concept. 

In [15] it is additionally assumed, that there is a model-theoretic semantics for 
the specifications, which induces a model class Mod (Spec) for each specification 
Spec. An instantiation of this requirement by models suitable for the specification 
of object-oriented systems is sketched in Sect. 4. A viewpoint concept used to 
manage the specification of heterogeneous aspects of such systems is introduced 
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1 Comp Exp | 

! 1 

; exp ; 

; . y ! 

[ Imp im P> Bod | 

Fig. 10. Specification component 



in [16] in this volume, where this concept lies orthogonally to the concepts of 
parameterization and abstraction realized in components. 

An abstract component is shown in Fig. 10. The import specification is con- 
nected to the body specification by an import connection imp: Imp — > Bod, 
where this connection should be a parameterization, i. e. it specifies, how the 
imported entities are used in the construction of the body. On the other hand, 
the export is related to the body by an export connection exp: Exp —> Bod, 
which is an abstraction from the details in the body, i.e. it specifies, how the 
abstract provisions in the export are realized by the body. 

UML subsystems can be seen as an instantiation of this concept, where the 
operations offered by the interfaces of a subsystem together with its specification 
elements form the export interface, and the realization elements correspond to 
the body of the component. The UML does not demand explicit modeling of 
the import of a subsystem, but we have added this by redirecting dependencies 
to the environment through interfaces with the stereotype «ODproxy>>, which 
have no realization in the subsystem itself but are instantiated by dependen- 
cies to the environment. The connections are then given by inclusions of the 
interface elements into the whole subsystem. The UML subsystem Handover in 
Fig. 5 can for example be interpreted as a component with the UML interface 
ExpHandoverControl in its export and the proxy interfaces ImpMediatorHandover 
and ImpCarrierControl in its import. The body then consists of all three interfaces 
together with the class Bod Handover. This component structure is made explicit 
in Fig. 11. 

There are two approaches to the semantics of components. In [15] a model- 
theoretic approach is sketched, which can be seen as a generalized version of the 
algebraic module concept in [17]. In this approach, depicted in Fig. 12, the seman- 
tics of an import connection imp is given by a construction Constr i mp : Mod (Imp) 
—> Mod (Bod), which builds models satisfying the body specification from models 
satisfying the import specification. An export connection exp is interpreted by 
a restriction Restr exp : Mod(Bod) Mod(Exp), which abstracts from the details 
of the realization in models of Bod, leading to models of Exp. Then, the model 
semantics ModSem(Comp): Mod(Imp) —> Mod(Exp) of a component Comp is 
just the composition ModSem(Comp) = Restr exp o Constr i mp . Thus, the model 
semantics of the subsystem Handover is a function transforming models of the 
import interfaces into models of the export interface. A model semantics for 
UML specifications together with constructions and restrictions is sketched in 
Sect. 4. 
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( ) ExpHandoverControl 



«functionblock» 

Handover 




Fig. 11. Component Handover with explicit component structure 



Comp Exp | > Mod( Exp ) 

exp\ 



[ Imp 



Mod(Imp) 




'odSem(Comp) 



Fig. 12. Model-theoretic semantics of component 



The second approach to component semantics, taken in [5], is based on trans- 
formations of specifications, where these transformations are supposed to some- 
how refine the specifications, and a class of inclusions of specifications. The 
transformation semantics Trafo(Spec) of a specification is then given by the class 
of all possible tranformations t : Spec => Spec' . Transformations and inclusions 
have to be composable by a composition operator o. Moreover, the extension 
property has to be satisfied, i.e. for each inclusion i: Spec 1 Spec 2 there has 
to be an extension function Extp. Trafo(Spec 1 ) —> Trafo(Spec 2 ), such that for 
each transformation t: Spec 1 => Spec [ with extension Exti(t): Spec 2 => Spec 2 
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Ext im^)\ 

%y . 

lmp’ ( lm P~ 



TrafoSem( Comp )( t) 



Fig. 13. Transformation semantics of component 



there is an inclusion il\ Spec \ Spec 2 . The semantics of a component, which 

now has to have an inclusion as import and a transformation as export con- 
nection, is then a function TrafoSem(Comp): Trafo(Imp) —> Trafo(Exp) with 
TrafoSem(Comp)(t) = Exti mp (t) o exp, which means that a component can con- 
struct transformations of the export specification from transformations of the 
import specification. This situation is shown in Fig. 13. 

A transformation based component concept for UML diagrams has already 
been examined in [18], where the transformations are inheritance relations be- 
tween elements in an export package and elements in the corresponding body 
package and inclusions correspond to the import of the elements in an import 
package. Considering UML subsystems the transformations correspond to adding 
the satisfying realization in the realization elements of the subsystem to the spec- 
ification in the export interface. Especially implementing classes as for example 
BodHandover in Fig. 11 are added to UML interfaces like ExpHandoverControl. 
The import inclusions are in this case obviously the inclusion of the elements 
marked as <<0D proxy » into the whole subsystem. 

The relation between model and transformation semantics could be given by 
the requirement, that there has to be a construction Constr i for each inclusion i 
and a restriction Restrt for each transformation t and these have to be compatible 
with composition. This means, for i\ \ Spec 1 c — > Spec 2 and i 2 : Spec 2 Spec 3 we 
have Constr^oij. = Constri 2 o Constr ^ and for t\: Spec => Sped and t. 2 - Spec' => 
Spec" we have Restrict! — Restr tl o Restrt 2 . Another interesting compatibility 
condition is compositionality of the model semantics with extension. This means 
for i: Spec 1 > Spec 2 and t: Spec 1 => Spec\ with Ext i(t): Spec 2 => Spec 2 and 
i!\Sped x Sped 2 we have Restr Ext .r t ) ° Constr p = Constr i o Restrt (i.e. the 
outer square in Fig. 14 commutes). 

In other words, the inclusions and transformations of the transformation 
semantics approach, which could in general be interpreted arbitrarily, can be re- 
quired to be sound w. r. t. the model semantics. After soundness has been proven 
for inclusions and transformations, the developer using the specification tech- 
nique does not need to deal with the model semantics directly anymore, but can 
use the transformation semantics, which enables the refinement of specifications 
by syntactical transformations. 
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R estr Ext . (t) 



/' X I 

Mod(Spec[) Con5/ 5 *- Mod(Speci) 

Fig. 14. Compatibility of model semantics with extension 



In order to instantiate the requirements requested by the import specifica- 
tion, the composition of components yielding larger components is useful. In 
Fig. 15 the components Comp 1 and Comp 2 are composed via the connector 
conn : Imp ± — > Exp 2 leading to a new component Comp 3 . Regarding the trans- 
formation semantics approach conn has to be a transformation, so that the ex- 
tension E xt i mp ( exp 2 ° conn) = ce' exists due to the extension property. Regard- 
ing the model semantics, there should be a restriction R.estr conn : Mod(Exp 2 ) — > 
Mod (Imp 2 ). Note, that compositionality of the model semantics can be deduced 
from the compatibility of transformation and model semantics: 



ModSem(Comp 3 ) 

= Restr exPs o Constr imp3 
= Restr exp o Restr Ext 



= Restr exPl o Constr imPl 



im P1 (exp 2 oconn) 

o Restr 



o Constrj 



o Constr 



imp 2 



conn O Restr exp 2 ® Constr imp 2 



= ModSem(Comp 1 ) o Restr conn o ModSem(Comp 2 ) 



The composition of components also leads to a composition operation for 
the instantiation to UML subsystems. With this composition architectures of 
UML subsystems with dependencies between their respective interfaces can be 
flattened by removing the redirections and proxy classes for satisfied imports 
and connecting the contents of the different subsystems directly. For example 
the architecture shown in Fig. 4 could be flattened to a single subsystem with 
no imports and just the interface ExpHandoverControl in the export as shown in 
Fig. 16. 

In [19] the concepts of union and multiple interfaces for transformation com- 
ponents based on high-level replacement transformations, a generalization of 
graph transformations, have been additionally treated. These concepts are also 
a useful line of future work for this instantiation of the abstract component 
concept, because especially multiple import and export interfaces arise very nat- 
urally from the usage of UML subsystems. 

Considering the notion of component in UML 2.0 introduced in the substruc- 
ture specification in [2], it seems promising to also interpret these as instantiation 
of the abstract component concept. UML 2.0 components have provided and re- 
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Fig. 15. Composition of components 




Fig. 16. Composition of Handover 



quired interfaces and ports, that can be used as export and import specifications 
in the sense of the abstract component concept. Moreover, protocol state ma- 
chines can be assigned to interfaces and ports, which allows to add constraints for 
the applicability of operations to the export and import specifications. Together 
with a model-theoretic semantics for (parts of) UML 2.0 similar to the one in 
the next section a formal notion of correctness could be derived for UML 2.0 
components, which could enhance the reliability of specifications significantly, if 
practicable methods to proof this correctness are provided. 
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4 A Model-Theoretic Semantics for UML Subsystems 

In this section we use object-oriented transformation systems (OOTS), which 
are variants of the transformation systems of GroBe- Rhode (see [8]), as a model- 
theoretic semantic domain for UML subsystems. The structure of OOTS and 
the specification by UML diagrams are presented in more detail in [16] in this 
volume. 

An OOTS is given by a control transition graph, where the nodes are labeled 
with object configurations and the transitions are labeled with sets of actions 
executed during the transition. Object configurations contain the values of at- 
tributes for all existing objects of the system, where links between objects are 
considered as a special case of attributes. Actions can be calls and returns of 
methods, signal occurrences, and assignments of attribute values. Each OOTS 
is built over a static algebra St containing data type sorts with corresponding 
data functions. The entities of an OOTS (data type sorts, data functions, object 
sorts, attributes, signals, and methods) are declared in a data space signature 
DSig. The possible configurations and actions w.r.t. this data space signature 
then form the data space D DSig- Figure 17 shows an example OOTS, where we 
can also see that the actions are parameterized with parameters from the static 
part for data type sort parameters and from the configurations for object sort 
parameters. Method calls, signal occurrences and attribute assignments get an 
additional parameter as the first one. This parameter denotes the receiving ob- 
ject for a method call or signal or the object, whose attributes will be changed, 
for assignment actions. 



'DSi/P 

data sorts: Bool 
functions: true: -> Bool 
false: -> Bool 
object sorts: Class 
attributes: Ink: Class -> Class 
methods: Class.meth(Class, Class): Bool 



St= 

^ ? Bool ={true,fa lse j 
true 5 ,=true 
false £,=false 



.... t x »T x 




Fig. 17. Object-oriented transformation system 



Each specification has an associated signature, which induces the data space 
of OOTS models for that specification. For example the import specification 
Imp of Handover as shown in Fig. 11 has the associated data space signature 
ImpSig given in Fig. 18. Note that we also give abbreviated names (in square 
brackets), which will be used in the following figures for readability reasons. 
The configurations of the data space D lmpI ; contain sets of existing objects for 
the object sorts ImpCarrierControl and ImpMediatorHandover. The actions in the 
data space are the occurrences occicc.eL and occicc.eU of the signals and the 
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Fig. 18. OOTS for the import specification 



call and return actions calliMH.sL and retiMH.sL for the method submitLoad and 
calliMH.su and retiMH.sU for the method submitUnload. The models Mod( Imp) of 
the import specification are now all OOTS for the data space D| mp y;, for which 
the statechart in Fig. 9 is satisfied, i. e. the signals executeLoad and executellnload 
can be sent alternatingly. Since no statechart is given for ImpMediatorHandover, 
we assume that both methods are always callable. Because an OOTS for the 
import specification will in most cases be a restriction (see below) of a refined 
specification, it will usually contain transitions labeled with an empty set of 
actions, denoting that the events are not visible w.r. t. ImpA 1 . A part of an 
example OOTS for the import of Handover is given in Fig. 18. 

For the body specification from Fig. 11 some entities are added to the data 
space signature shown in Fig. 19, namely object sorts for the class Bod Handover 
and the interface ExpHandoverControl, the attributes of BodHandover and the 
methods available for BodHandover and ExpHandoverControl. Now we can con- 
struct a minimal model for the body specification, a part of which is shown in 
Fig. 19. This model is minimal in the sense that the internal structure of im- 
ported methods is omitted. This means they are only represented by their call 
actions and return actions as e.g. the method submitLoad in the example. For 
each invocation of an imported method it contains all return actions, which an 
instantiation of the import could possibly generate, since the body model has to 
be able to interact with arbitrary instantiations. 

In Fig. 19 we can also see, how inheritance is represented in an OOTS: 
Since, the class BodHandover inherits from ExpHandoverControl, each object of 
BodHandover is also an object of ExpHandoverControl, e.g. the object blr in the 
object configurations is the object ehc. The call and return actions are included 
for both, the object and method of the implementing class and the object and 
method of the abstract class. 

According to the model theoretic approach for the semantics of components 
presented in [15] and discussed in Sect. 3 the semantics ModSem(Comp) is 
given as composition ModSem(Comp) = Restr\ mp o Constr exp . The construction 
Constr\ mp : Mod( Imp) — > Mod( Bod), which is the semantics of the import inclu- 
sion imp, can now be obtained by synchronizing any given model in Mod{ Imp) 
with this minimal model leading to a model in Mod( Bod), which uses the im- 





B. Braatz et al. 



'ExpSig= 

data sorts: Bool, WT, Ml 
object sorts: EHC 

methods: EHC.IW(EHC, WT, Ml): Bool 

EHC.uW(EHC, Ml): Bool 



St= 

%ool=! true - false ) 
5% r ={raw,tyl,ty2} 
St w ={0,1,2,...} 




Fig. 21. Restricted OOTS for the export specification 



ported model to realize the imported signals and methods. This synchronization 
is done by inserting the structure of imported methods from the import model 
into the minimal model. The syncronization of the OOTS part of the minimal 
model from Fig. 19 with the part of an import model from Fig. 18 is shown in 
Fig. 20, where the transition labeled with the empty action set, which represents 
the execution of the method submitLoad, is added to the minimal model of the 
body. The part of the minimal model dealing with a return value of false is not 
contained in the synchronization, because the import model returns true for this 
invocation. 

Finally, the restriction R.estr ex p , which is the semantics of the export inclusion 
exp, hides all parts of models of Bod, except for the object sort of ExpHandover- 
Control and its associated methods. The restriction of the partial body OOTS 
from Fig. 20 is shown in Fig. 21. 



5 Conclusion 

Along the example of the specification of a lrolonic transport system it was 
shown, how the advantages of the component notion can be carried over to 
the development of embedded, object oriented systems. This was achieved by 
establishing a correspondence between the UML subsystem and the IEC function 
block notion. In order to further enhance the usability of this concept, as well 
as the complementary concept of viewpoint consistency in [16], more aspects of 
specific interest for production automation, e. g. real-time constraints, will be 
integrated into the model semantics and specification techniques based on, but 
not limited to, the UML will be examined w.r.t. these aspects. 

In order to have available well defined composition operations and a formal 
semantics we sketched out how UML susbsystems can be understood as compo- 
nents in an abstract and formal framework. This relation also has to be worked 
out in more detail to make available code generation, correctness notions, etc. for 
the modeling of components and function blocks with subsystems. Especially the 
relation between the different formal composition operations (horizontal compo- 
sition, union, multiple interfaces) and the UML syntax has to be clarified. 

Furthermore, the relations to the UML meta-model and components in the 
sense of UML 2.0 will be examined, in order to develop guide lines for tools 
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supporting the concepts shown in this paper and the orthogonal concepts in [16]. 
More specifically, the component concept would induce a notion of correctness 
of components together with administration guidelines for such components, 
which could e. g. minimize and observe the proof obligations for correctness and 
composition of components. 
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1 Introduction 

“Specification” is a very complex concept. This complexity results initially from 
the questions “What is the purpose of a specification? What is the subject of 
a specification?” and “Who writes a specification?”, which in turn lead to the 
questions “What methods and processes are used for specification?” . Answering 
these questions in detail and finding a definition for the term “specification” 
that encompasses the full extent and depth of this term represents an enormous 
academic challenge; it is also of great practical relevance. Because even if analyt- 
ical deductions can be made from a specification that provide an understanding 
in retrospect, the actual milestones of a correct and efficient specification are 
in fact a goal-oriented synthesis of the subject of specification as a unit and its 
proper functioning in reality. 

There are two sides to a specification. On the one hand, it involves method- 
ically identifying all its objectives correctly and unambiguously and defining 
them clearly. On the other hand, a specification is a result, a condensed version 
of deliberations; it is also an independent manifestation of thoughts, methods 
and a selection of variants in the form of more or less substantial documentation 
and more or less formal or formalised illustrations that take the form of text or 
images. A specification is thus also a touchstone and a mirror for the results it 
generates. 

It is impossible to carry out scientific research on the methods and defini- 
tions of a specification without taking into account its technical field and area 
of application, or the people involved in the specification process. Each tech- 
nical field has developed its own range of methods and definitions; however, 
these are questioned whenever new technologies and paradigms promise better 
or new solutions. From a scientific point of view, research about the migration 
of specifications is very revealing in this respect. Particularly given its place in 
the starting phase of a project, a specification is crucial to the remaining project 
process. 
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2 Domains Traffic (Control) Systems and Models 

The focus research programme “Integration of Software Specification Techniques 
with Applications in Engineering” has decided to highlight traffic control sys- 
tems to consider these scientific issues in more detail; this technical field unites 
different perspectives, hence its attraction for scientific research. Until only a 
few decades ago, this field had its own established development methods and 
notations based on electromechanical control and actuators, and wired commu- 
nication, which meet the very high requirements regarding the safety of the 
persons involved in this field. Given the opportunities offered today by digital, 
hardware and software technologies, or mobile radio transmission, as well the 
traditional engineering skills and innovative computing knowledge we have, we 
are presented with the challenge to use and further develop the opportunities 
offered by the new technologies to achieve higher operational performance and 
efficiency in this safety-relevant field. 

Migrating the immense capital spending volume and the installed traffic 
control systems for road and rail transport is a task of a national economic 
scale, which concerns the whole continent and will take decades to implement. It 
started two decades ago with several European programmes such as Prometheus 
for road transport or ETCS for rail transport, and has been pursued in numerous 
projects within the european framework research programmes. 

The many update issues, ranging from changes to traffic routes, to vehicle 
procurement or technical equipment, never question the system itself; however, 
the question generally arises as to whether it is possible to concentrate less on 
generic models or basically invariable universal domain models, and to shift the 
focus instead to specific tasks using modularisation and parameterisation. There 
have been first steps in that direction, such as the European Formal Methods 
Rail Initiative [Fm], the Open Track Model [Hill], or the RailML project [Hii2], 
whose aim it has been to create standard product data models. These have many 
advantages, such as data exchange, simulation modelling or module integration. 
Some conceptual approaches are also promising, such as generic models with 
a wide variety of definitions, as those presented by [Me] or, in this volume, by 
[RJZ]; these may be developed further to form a standard basis for specifications. 

3 Reference Case Study 

To study different specification techniques that are crucial to the success of a 
project, a comparative approach was chosen. This allowed focusing on a highly 
realistic sample case without digressing into technical detail. 

To avoid restricting specification requirements to achieving specific function- 
alities, we chose a highly topical example as a case study, the level crossing with 
barriers. It integrates the high demand for safety relevance with the effects and 
repercussions this would have on the specification by expressly excluding and 
avoiding requirements that were not permitted. Due to their hybrid dynamics 
with discrete event and continuous behaviour, level crossings with barriers have 
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frequently been studied and referred to. With the support of Deutsche Balm 
AG, we constructed a complex case study and delivered its documentation as a 
benchmark for this investigation [JS,HPSS,Sc4]. This provided a common basis 
and reference for the work on specification methods and scientific study. As the 
papers in this volume show, a wide variety of approaches, in terms of both the 
methods and the definitions used, has been the result. 

To compare the individual approaches, we organised a number of workshops 
e. g. [Sc4]. Given their common object of reference, the presentations and discus- 
sions went into far more depth than is usual. In a collaboration with the FORMS 
(Formal Methods for Railway Management Systems) series of conferences, our 
reference case study was also a required reference for conference papers [Scl,Sc2, 
Sc3,TS], 

Given its accessibility for the scientific community, the reference case study 
was also widely used internationally. We would like to mention in particular 
the work carried out by Italian partners [Im], or the French initiative for for- 
mal specification techniques, which used our reference case study as a basis for 
its research [BBM]. Work carried out in this field has also been applied in an 
international initiative for developing a domain model for the railway sector [Tr] 

4 Demonstrator Level Crossing 

In order not to limit the scientific treatment of specification techniques to theory 
and form, an experimental phase provided the opportunity to test, validate and 
compare their results. For this purpose, a scaled model of a level crossing and a 
train model were conceived, constructed and validated using simulation [ESSS1, 
ESSS2,HKSS,HPSS,JS]. This provided a test environment that was affordable, 
and which was frequently used by the working parties for their experiments on 
site at the Institute for Traffic Safety and Automation of Braunschweig Technical 
University. 



5 Scientific Methods in Case Studies and Real 
Experiments 

In the natural and engineering sciences, real experiments are an essential part 
of research, although cost and efficiency constraints have led to a continuous 
shift in methods towards using digital simulation experiments in these fields, 
too. But epistemology states that the ultimate validity of a hypothesis or model 
can only be shown in a direct real experiment. Before implementing a project 
in real life, experiments are first carried out on a smaller scale using simulators 
or mock-ups, or on the so-called technical scale. This use of scientific methods 
is quite established in sciences and engineering; however, it is often still viewed 
as redundand by computer scientists. 

“Integration of Software Specification Techniques with Applications in En- 
gineering” not only means integrating descriptive methods and process models, 
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it also implies addressing the differences in scientific culture there are between 
these (two) worlds. Real experiments are viewed as normal in physics, biology 
or chemistry; but engineering science goes even further. Natural scientists are 
focused on the acquisition and analysis of knowledge. Engineering scientists, on 
the other hand, strive to achieve real-life goals by applying synthesis in tech- 
nical facilities. They therefore need to take into account the specific physical 
laws of a technical field in order to complete a synthesis in the technical con- 
straints given, using their technical expertise. Computer scientists for their part 
primarily consider formal models and laws as abstract mental constructs. Their 
“experiments” are not restricted by the inertia of physical processes; computer 
scientists are therefore surprised by the physical constraints of their engineer- 
ing counterpart, which responds within the constraints of the inertia inherent in 
its own laws. Only when the chain of events and effects incorporating physical 
and data-related factors has been completed with the integration of engineer- 
ing and information science concepts, can we progress to specifications that are 
sustainable in practice. 



6 Overview 

The papers below that use the reference case study Traffic Control Systems have 
approached the inherent topic in a number of ways and have studied its aspects 
in detail from their respective points of view. 

The first paper by Hansel, Poliak, Slovak and Schnieder, project KNOSSOS 
[HPSS], provides a detailed introduction to the reference case study. It starts 
with the question whether formal specifications are required in railway signalling 
technology. This is followed by a detailed presentation of the case study including 
normal functioning and malfunctioning behaviour. The second part presents the 
concept for and technical implementation of the demonstration model; it also 
describes integration options for coupling executable specifications. 

The paper by Arabestani, Bitsch and Gayen, project SafeRail [ABG], ad- 
dresses two aspects. Firstly, it shows how the system definition is prioritised 
using UML descriptive methods. This applies to its structure, the dynamics of 
the internal control behaviour using state-transition charts, and to the reactions 
between train, control centre and level crossing control. The authors have used 
message sequence model scenarios for this purpose. They have also applied the 
safety pattern concept as an example to explain the methodical formalisation of 
safety requirements as a system. 

The paper by Berkenkotter, Bisanz, Hannemann and Peleska, project HY- 
BRIS [BBHP], extends UML by hybrid aspects with real-time properties and 
semantically defines it to match the special dynamic aspects of this technical 
field more closely. 

Using the highly complex example of a new railway interlocking system, 
Rastocny, Janota and Zalrradnik [RJZ] show in their paper how UML expres- 
sions can be used for specifications of real industrial and complex tasks in the 
railway sector. They give details of different UML modelling levels, such as use 
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case, class and sequence diagrams or state charts, and use them for different 
specification tasks. This is the first time the specification of a signal box has 
been comprehensively documented in a scientific paper. 

In addition to the papers compiled here, which relate directly to the refer- 
ence case study, the focus programme included other projects (from other subject 
areas) that also used this study as a reference (project ForMoSA by Reif, Schell- 
horn, Thums, Ortmeier [OTSR,TSOR], project USE, by Damm, Klose, Westplral 
[BBDKWW] and also the second contribution of the projekt KNOSSOS [Ei] ) . 
These have been published in others sections of this volume, since they have 
a different focus. The subjects include operational specification methods, fault 
detection etc. 

7 Results 

As new and successful results of the subject area Traffic Control Systems the 
following can be summarized: 

— The research programme provided one of the world’s first comprehensive 
analyses within the railway transportation domain by means of computer 
science methods. Its results are an important contribution to the similar 
oriented European activities FME, FORMS and recently TRain etc. 

— A realistic and full detail reference case study of the level crossing control 
was created. It includes all kind of the multifaceted domain system features. 
Since other international research groups applied the case study too, an 
international accreditation and visibility was achieved. 

— To demonstrate experimentally results achieved in the field of computer sci- 
ence a physical model of the case study was designed and build. It is directly 
accessible for experiments by standard interfaces; a remote control via inter- 
net is intended. 

— The main conclusion of the research is that the contemporary techniques 
(e.g. UML) are not sufficient in order to achieve unambiguous and verifiable 
software specifications for this specific and safety relevant domain. Hence 
several formal extensions were developed and investigated. 
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Abstract. As domain modelling has been identified as a key issue for 
putting formal specification techniques into engineering practice, two 
reference case studies were elaborated within the research programme 
“Integration of Software Specification Techniques for Applications in En- 
gineering” . One of them, coming from the railway transportation control 
domain and using an example of a radio based level crossing control 
system, was developed at the Institute of Traffic Safety and Automa- 
tion Engineering. A physical railway model demonstrator was designed 
and developed as a means of comparison and validation for the formal 
specifications coming from partners involved in the research program. 



1 Introduction 

With regard to outstanding research issues in software specification, theoretical 
computer science often demonstrates the applicability of newly developed for- 
malisms by means of small, well defined and easy-to-understand examples. Well 
known and widely studied problems are a generalized railroad crossing [HJL] 
and a steam boiler controller [ABL]. With good reason, the settings of such 
small-scale examples are generally restricted to the problem characteristics at 
hand. However, various aspects of practical relevance are commonly neglected 
and their combination cannot be studied in such settings. Industrial case studies 
might seem to be a good way out, but on the other hand tend to be complex, 
i.e., not easy to understand for non-domain experts, and due to their size, of- 
ten require huge resources to implement. In addition, the settings of industrial 
case studies for some other good reasons often are not published in complete 
detail which makes it impossible to apply and compare different specification 
techniques and approaches for their integration on a common reference. Accord- 
ingly there is a need for, one might say, virtual industrial case studies that are 
realistic, well formed and publicly accessible. 

Two case studies have been provided within the focus research programme 
“Integration of Software Specification Techniques for Applications in Engineer- 
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ing” of the German Research Council (DFG). They aim to close the aforemen- 
tioned gap and serve as a reference for the comparison of different approaches. 
This paper deals with the case study from the traffic control systems domain. The 
problem is the specification of a radio based railway level crossing control appli- 
cation, which is distributed over a train-borne control system (on-board system), 
a level crossing control system and an operation centre. The setting described 
in the next chapter is reasonably realistic, as it is taken from the specification 
of a new radio based train control system that has been developed for the Ger- 
man Railways [Ff|. It contains various kinds of problems that require the use of 
different specification techniques and, at the same time, is limited with respect 
to complexity and work load. It is important to note that the setting of the case 
study is not intended to resemble a real application and that simplifications have 
been made on purpose in accordance with the aims of the case study. 

To validate the results of the projects, simulation in requirements engineer- 
ing [Kr] as well as in system design and realization is needed. The problem is 
that there is no real continuous way from formal work on paper to a real im- 
plementation. In other domains, e. g. chemical process technology, an additional 
step of development, also called “scaling up” is widely accepted to handle this 
problem. It means to experiment in low scaled processes, before starting the real 
operation. Such experiments also seem to be necessary in software engineering, 
but not many experiences have been reported [Sn]. 

The purpose of validation requires a real testing environment with its specific 
properties. One of these is a certain degree of inaccuracy in detecting the system’s 
current state. Implementing this in software leads to a high model complexity. 
This was one reason why it has been decided to build a physical railway model for 
validating the research results of the focus research programme under nearly real 
operating conditions. The paper firstly presents the objectives and features of 
the reference case study (Chapter 2) [SJ]. Secondly (Chapter 3), the functional 
design of the demonstrator, its implementation and first experiences with the 
integration of formal control specifications and their validation are presented. 

2 Reference Case Study 

2.1 Formal Specification in the Railway Signalling Domain 

In [Bj] domain engineering is called a prerequisite for a new software engineering 
paradigm. Domain modelling is the activity of explicating all the generic knowl- 
edge of a domain that might ever become relevant for a systems engineering 
step. In particular, a domain model has to be free of all requirements of the sys- 
tems to be developed. Thus, domain modelling allows a separation between the 
explication step and the requirements specification. The necessity to establish 
consistent relations between a domain model and a software specification moti- 
vates the studying of domain modelling and domain-based support for software 
specification in the context of the DFG focus research programme. 

Several domain-oriented approaches are known from software engineering, 
which may be considered to support other specification techniques. Domain- 
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specific languages [Ni] are tailor-made to express problems of a restricted domain, 
often in a declarative way. They are easy to use for domain experts and in many 
cases allow for automatic code generation. A modification or extension of the 
underlying domain model, however, is expensive and limits flexibility of use. 

In [BBM] a formal domain model is presented using the RAISE specification 
language. In combination with a formal requirements specification the approach 
allows formal analysis and proofs. However, a formal domain model is difficult to 
construct, maintain and understand for domain experts. A linguistic approach is 
described in [OS]. A normative domain-specific language can be constructed on 
the basis of a lexicon and a set of sentence patterns. The lexicon (expert termi- 
nology) defines a list of words together with their meanings, that can be used in 
a domain (see [Ui] for a lexicon of railway terminology). Schemata for construct- 
ing correct sentence patterns ensure an informally but unambiguously defined 
meaning of complex sentences. The linguistic method seems highly promising 
for a comprehensible domain approach for software specification. A normative 
human-style language is easy to learn, adapt and use for domain experts. More- 
over, it is independent of a specific domain and not biased towards or against a 
certain design method. 

Specialists in the train control systems domain generally are not familiar 
with formal software specification techniques. Nonetheless, they are increasingly 
confronted with the necessity of applying formal methods throughout the entire 
product life cycle in order to ensure high quality results for problems of growing 
complexity. 

2.2 Regular Behavior Definition 

The problem chosen for the reference case study is a decentralized radio-based 
control system for a railway level crossing, where a single track railway line and 
a road cross on one level. The intersection area of the road and the railway line 
is called the danger zone, since trains and road traffic are not allowed to enter 
it at the same time to avoid collision. The railway crossing is equipped with 
barriers and road traffic lights. Traffic lights at the level crossing consist of a red 
and a yellow light. When the yellow light is shown road users (drivers, cyclists, 
pedestrians etc.) should stop at the level crossing if possible. The red light means 
that the level crossing is closed for road traffic and road users are not allowed 
to enter it. The yellow and red lights must never be on together. When both 
lights are off, road users may enter the crossing area. Half arm barriers are used 
to block the entry lane on either side of the level crossing. Since there are no 
barriers for the exit lanes, road users may possibly enter the crossing area on 
the opposite lane. Although this behaviour constitutes a severe contravention of 
the traffic regulations, it can be frequently observed due to long waiting times 
at closed level crossings. This has to be taken into account for the level crossing 
control system by monitoring a maximum closure time. 

The traffic lights and barriers at the level crossing are controlled by the level 
crossing control system. It is activated when a train is approaching the level 
crossing (see Figure 1). In the activated mode the level crossing control system 
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Fig. 1 . The regular scenario of the operational railway process 



performs a sequence of actions according to a specific timing in order to safely 
close the crossing and to ensure the danger zone is free of road traffic. First, 
the traffic lights are switched on to show the yellow light; then after 3 seconds 
they are switched to red. Approximately 9 seconds later, the barriers start to be 
lowered. If the barriers have been completely lowered within a maximum time 
of 6 seconds, the level crossing control system signals that the level crossing is 
in its safe state, thus allowing the train to pass the level crossing. When the 
train has completely passed the crossing area the level crossing may be opened 
for road traffic again and the level crossing control system switches back to the 
deactivated mode. 

The main components of interest for software specification are the train-borne 
control system, the trackside level crossing control system and the operations 
centre. These main components can communicate with each other by means 
of mobile radio communication. Transmission times on the radio network may 
vary and have to be considered. Radio telegrams even may get lost on the radio 
network. 

The approaching of a train at the level crossing is traditionally detected by 
trackside equipment or signal staff such that the level crossing can be closed 
in time to let the train pass through without any delay or braking action. In 
modern radio-based train control systems the activation of the level crossing 
is based on continuous self-localization of the train and mobile communication 
between the train and the decentralized level crossing control system. A route 
map on board the train contains the positions of potential danger points at level 
crossings and provides additional information for the train on when or where to 
send an activation order to the respective level crossing control system. 
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Self-localization is realized by balises, i. e. small transponders between the 
rails, transmitting an identification signal to the train. Comparison of this in- 
formation with the digital route map stored on board the train allows an exact 
positioning of the train. 

When the on-board system detects that the train is approaching a level cross- 
ing it sends a radio message to the level crossing control system to switch on the 
road traffic lights and to lower the crossing barriers. It will also set a braking 
curve for the speed supervision system, which will make the train stop at the 
potential danger point in a failure situation. The level crossing control system 
acknowledges receipt of the activation order to the train. After receipt of the 
acknowledgment the on-board system waits an appropriate time for the level 
crossing to be closed and then sends a status request to the level crossing con- 
trol system. If the level crossing is in its safe state, this will be reported to the 
train. This allows the train to cancel the braking curve and safely pass over the 
level crossing while supervising the regular speed profile. The triggering of the 
vehicle sensor at the end of the level crossing will cause the barriers to be opened 
again and the traffic lights to be switched off. 



2.3 Failure Behavior Definition 

Possible failure conditions have to be taken into account to achieve safe control of 
the level crossing and the train. A main cause of failures is the malfunctioning of 
sensors or actuators. Faults may also occur in the main physical structures. Fail- 
ures of communication systems may affect the communication between control 
systems and devices as described above for radio networks and mobile commu- 
nication. Last, but not least the control systems themselves may fail. 

Defective devices will be repaired after some time so that the occurrences of 
both failures and repairs have to be taken into account. While failures may occur 
at any time, repair of defective devices in the case of non-recoverable failures, 
mostly physical components or sensors and actuators, will not take place when 
there is a train approaching or passing the level crossing. 

In the case study only a limited number of failures are considered (Figure 2): 
failures of the yellow or red traffic lights (to be considered separately), the bar- 
riers, the vehicle sensor and the delayed receipt or loss of telegrams on the radio 
network. The traffic lights and the vehicle sensor are constantly monitored and 
defects are immediately reported to the level crossing control system. Failure of 
the barriers can only be detected by time-out when barriers fail to reach the up- 
per or lower end position in time or at all. The required behaviour of the control 
systems under failure conditions will be described below according to the time 
sequence of failure occurrences and control reactions (see also Figure 2). 

The level crossing control system is able to detect the occurrence of failures 
of traffic lights and vehicle sensors. It immediately reports such an event to the 
operations centre, which is able to have the defective component repaired. After 
repair, it may be necessary to carry out re-initialisation of the level crossing 
control system (e. g. barrier failure). This does not imply that train operation 
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Fig. 2. Technical faults to consider within the operational process 



is suspended on the affected section of track for the time up until the repair is 
carried out. 

After having sent the activation order to the level crossing, the train waits 
for an acknowledgment. The train will send no status request until the acknowl- 
edgment has been received. The following applies in all cases, whether the train 
has sent the status request having received the acknowledgment or not. If the 
train does not subsequently receive the status report indicating that the level 
crossing is in its safe state before entering its breaking curve, the on-board sys- 
tem will apply the brakes until the status report has been received or the train 
has come to a standstill. If the status report is received before the train comes to 
a complete stop, the brakes are released and the train can continue. Otherwise 
the system causes a message to appear on the driver’s display, asking the driver 
to make sure that it is safe to cross the level crossing and to give confirmation 
via the display unit that the level crossing is in its safe state. If meanwhile the 
status report has been received, the message is cancelled from the display, the 
brakes are released and the driver does not need to give confirmation. Otherwise 
the driver has to confirm that the level crossing is in its safe state in order to 
release the brakes and continue the journey. 

After receipt of an activation order from a train, the level crossing control 
system immediately checks if the level crossing control should be activated, and 
accordingly will or will not send an acknowledgment to the train. The level 
crossing control system will not be activated if the red traffic lights or the vehicle 
sensor are defective. If the level crossing control system has been activated, 
then, after a minimum green time has passed since the last deactivation of the 
level crossing, the yellow traffic light is switched on for 3 seconds. If the yellow 
traffic light becomes defective either before or during the yellow light period, 
the traffic lights are switched to red and the red light period of 9 seconds is 
extended accordingly by the lost yellow light time. If the red traffic light fails after 
activation of the level crossing control system the closing procedure has to be 
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cancelled unless the lowering of the barriers has already begun. The level crossing 
must be reported to be in the failure state if the barriers fail to be completely 
lowered within 6 seconds from the start of lowering or if in the meantime the red 
traffic light has become defective. Upon request, the current status of the level 
crossing will be reported to the train. 

If the vehicle sensor becomes defective, the level crossing control system 
cannot be deactivated anymore by a passing train. Accordingly the barriers 
remain lowered and the red traffic light remains switched on. However, the level 
crossing control system monitors a maximum closure time of 240 seconds starting 
from the time the red lights are switched on. After the maximum closure time has 
elapsed, no positive status report is sent to the train. The level crossing control 
system will report the exceeding of the maximum closure time to the operations 
centre. The operations centre finds out, whether the train has already passed the 
level crossing or not. In the first case, the operations centre sends a deactivation 
order to the level crossing. Otherwise the train is still approaching or just passing 
over the level crossing and the rules for late arrival at the level crossing apply 
as described above. 

Regarding redundancies and symmetries within the geometry and equipment 
at the level crossing, it was recommended that any multiplicity of devices or 
processes should be ignored (e. g. number of trains, level crossings or directions 
of train traffic). For the purpose of specifying non-finite behaviour, the track may 
be assumed to be virtually circular. However a clear separation of different laps 
made on the track is recommended, so that no two successive closing procedures 
of the level crossing overlap. Therefore it might be necessary to synchronize 
e.g. the opening of the barriers with the next sending of an activation order 
by the train. Also note that the train driver may slow down, stop or speed 
up the train at any moment or location. This must not affect the safety of 
the level crossing control system. The train may be assumed to always run 
in the same direction. The described reference case study combines different 
aspects of specification problems from the traffic control system domain and 
was successfully used for a comparison of properties and practical capabilities 
of different formal specification techniques. The more detailed reports can be 
found in the papers of [OTSR,TSOR,BBHP, ABG,BBDKWW,Ei] . 

3 Model Demonstrator 

3.1 Functional Design 

Software validation in the context of an assessment process in railway engineering 
today often requires integration of hardware components (e.g. validation of the 
European Train Control System in railway laboratories in Germany and Spain) . 
This has the advantage of highly unambiguous and therefore trustworthy results. 
The requirement for real time operation capability and the specific inaccuracy 
in behaviour were the main reasons for the chosen hardware realisation of the 
validation environment. 
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Fig. 3. Functional structure of the demonstrator 



To achieve the aim of formal specification validation, several practical prob- 
lems have to be taken into account. Firstly, the use of the physical model has to 
be effectively available for all participants of the research programme. To solve 
this problem an internet connection was included in its functional design. 

Secondly, within various research projects of the focus research programme 
different modelling languages supported by different software tools are used. 
Some of the applied formal techniques do not allow modelling of all aspects 
included in the reference case study specification. Thus a suitable tool coupling 
the concept with a flexible architecture of the railway model control system is 
required, which will make it possible to join model parts designed by different 
tools into one virtual model. 

In order to meet all requirements mentioned at the outset, a functional struc- 
ture of the demonstrator control system was derived (Figure 3). The structure 
consists of three main functional groups. Besides the external control algorithm 
model, developed according to the case study specification, these are the basic 
functions of the demonstrator and the group of experimental functions. Addi- 
tionally a remote control algorithm integration via the internet must be possible. 
In the following sections a more detailed description of each demonstrator func- 
tion block will be given. A detailed explanation of the railway model device can 
be found in chapter 3.3. 

The main task of the experiment control is to prepare, configure, start and 
stop the experiment as well as the data recording and processing and the final 
visualization of the obtained results. Also a suitable mode of environment control 
has to be chosen. In order to provide the remote experiment control via the 
internet, a suitable web interface is needed which supports experiment definition, 
control, visualization and exporting of results. 

The environment control has to simulate the possible influence of the en- 
vironment of real operating conditions. At the same time the controllability of 
the environment influences must be guaranteed. On the one hand, these are 
the inputs resulting from potential train driver behaviour and from possible ac- 
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tions initiated by the operation inspector supervising the functionality of the 
level crossing. On the other hand, the occurrence of hazardous failures has to be 
simulated. Failures of yellow or red traffic lights (to be considered separately), 
barriers, the vehicle sensor and the delay or loss of telegrams on the radio net- 
work are considered. One of three possible modes of environment control has to 
be selected before starting an experiment. Specifically a manual on-line environ- 
ment control using the command desk or the control computer can be replaced 
by a concrete definition of an experiment scenario specifying the environment 
influences. 

The railway model control system represents a direct interface to the railway 
model device. Its task is to bring together all control commands from higher 
functional layers, to test their admissibility and to adapt them to the model 
device requirements. Also the actual operating states of the model device com- 
ponents are to be acquired and transmitted in a suitable form to the experiment 
or environment control as well as to the external control algorithm model. 

As already mentioned, the control algorithm models are designed by differ- 
ent external project partners participating in the research program. The model 
functions, which have to be implemented in accordance with the case study spec- 
ification, can be dedicated to three functional parts: train-borne control system, 
trackside level crossing control system and the operations centre. The modelling 
of these functional blocks can be can be implemented in the form of a single 
model or as three separate models. A separated solution makes it possible to 
combine different parts of the control algorithm model from different projects 
also using formal modelling languages which are not suitable for modelling all 
required system aspects. 

A refinement of the functional structure in Figure 3 and its hardware allo- 
cation are shown in Figure 4. It shows one configuration option with the user 
control algorithm model consisting of three separate parts running on three 
different computers. To couple the control algorithm models with demonstra- 
tor functions, an Inter Tool Communication (ITC) framework for integration 
of application programming interfaces (API) is required. If the user’s modelling 
language is not able to describe all the functional aspects of the case study 
specification, it is possible to add the missing functions by activating one of the 
demonstrator auxiliary functions. 

3.2 Experimental Function Implementation 

Figure 4 shows the implemented functionality and communication in the exper- 
imental functions. It contains the experiment control and environment control 
which were realised in MATLAB/Simulink® [Ma]. 

The experiment control can be defined off-line as a scenario before the start of 
the experiment. For this purpose a special graphical user interface was designed. 

Using the interface, a control file is generated which can be directly processed 
by the environment control. The control file defines train driver and operating 
inspector actions as well as failure occurrences in relation to the time from the 
start of the experiment. The experiment can be controlled on-line during the 
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Fig. 4. Realization of the demonstrator control using a distributed control algorithm 
model 



experiment run using a train driver interface. Failures may also be introduced 
on-line directly from the railway model device. 

For remote experiment control, a web interface is being realized (control file 
generation, train driver interface). It provides video supervision of the whole 
experiment including a detailed view from the vehicle cab. 

All communication activities between the control algorithm model and the 
demonstrator are stored with the corresponding time stamp in an experiment 
log. A filtering tool can be used to extract the desired information for post- 
processing by the experiment evaluation. 



3.3 Basic Function Implementation 

The basic demonstrator functions (railway model control system and railway 
model device) were implemented through the development of specific hardware 
components. The main items are the vehicle (train) and trackside components 
(traffic lights, barriers, vehicle sensors, balises and switches). Special attention 
was paid to the design of a suitable communication between static and mobile 











106 



F. Hansel et al. 



components of the railway model device and its control system. The implemented 
concepts are based on a suitable abstraction of properties of specific components 
of the railway model device. In the following sections the implementation of all 
basic demonstrator components will be presented in detail. 



Vehicle. The train vehicle, the mobile element in the case study, is located 
on the track and passes the level crossing at intervals. Communication was im- 
plemented between the demonstrator computer and the vehicle. The originally 
considered concept [Bo] used a communication module based on DECT (Digital 
Enhanced Cordless Telecommunications) for wireless communication. After ini- 
tial experiences the DECT communication was replaced by a standard module 
for wireless LAN (WLAN). 

The vehicle’s functionality includes speed control and the acquisition of posi- 
tioning information. This functionality is performed by a set of electronic boards 
mounted on the rear part of the vehicle (Figure 5). This set of electronic boards 
also provides a realistic reproduction of the acceleration and braking behaviour 
of the vehicle. A video camera is installed in the vehicle cab to transmit the train 
driver’s view to the internet. 

A microcontroller board is used to control the vehicle speed and acquire its 
precise position. This item of electronic equipment is located on the lower of the 
electronic boards shown in Figure 5 at the back of the train vehicle. To allow 
external access to this board, it is connected to a serial port of the PC located 
on the upper and smaller boards shown in Figure 5. This is an industrial PC 




Fig. 5. A train vehicle 
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running the Linux operating system with a special daemon that provides a TCP 
service to provide access to the train vehicle via (wireless) LAN. 

The absolute position of the train vehicle on the track is acquired using 
balises, which are installed with small transmitters on the track. They are de- 
tected by a receiver on the rear of each train vehicle. Each balise transmits a 
unique code, thus enabling the application using the demonstrator to determine 
the correct position of each train vehicle. 

The system of balises uses infrared light as its transmission medium. They are 
spaced at intervals of about 30 cm (12 inches). An incremental encoder fixed to 
one of the train vehicle’s axles provides its relative position between the balises. 

The overall positioning information consists of the number (code) of the last 
balise passed and the distance from it (calculated from counting the impulses 
from the incremental encoder). 



Track side components. Each individual trackside element (barrier, traffic 
light, axle counter and switch) is able to communicate with the trackside network 
of the demonstrator and to check that its hardware is functioning correctly. 

Each trackside component is equipped with its own controller and control 
hardware. The controller is exactly the same item of hardware in each of the 
elements mentioned. It is a small board with a microcontroller that has a built-in 
CAN unit and four light-emitting diodes, which indicate its current state. Since 
this board is designed as a generic platform that contains common hardware 
functions, only the software has to be customized for the functionality required 
by the specific application. 

The control hardware (or baseboard) is specific to each trackside element. All 
the different control hardware boards have identical sockets that fit the controller 
board plug. 

As an example of the trackside hardware, Figure 6 shows a demonstrator 
traffic light. The design described made it possible for each component to have 
only one electrical connection to the rest of the demonstrator system that carries 
the power and the communication lines. 



Communication. A key function of the railway model device is the commu- 
nication between the different hardware components and the application using 
the demonstrator (the models and tools). This communication only provides 
data exchange between hardware components involved in the simulation of the 
validation environment. It is not a part of the environment control, which is 
responsible for the generation of different communication failures. 

However, highly reliable communication is necessary in order to guarantee 
controllability of the experiment. 

Firstly, the communication inside the railway model device will be described. 
From a hardware point of view, it consists of two main levels: an upper level, 
which contains the application using the demonstrator; and a lower level, which 
contains all the hardware and provides a single point of access to its functionality. 
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Fig. 6. Traffic light with its electronic 



Figure 7 shows the overall communication structure of the demonstrator focusing 
on this lower level (not on the control models). 

The lower (or hardware) level itself can be divided into three different sub- 
levels. The uppermost of these sublevels contains the functions to access the 
hardware from a single connection. It is implemented as an item of software 
providing a TCP service and running on a PC called the “central demonstra- 
tor server” (CDS) with a Linux operating system. This software uses standard 
functions for providing this kind of service (e.g. as used by web servers). 

The next hardware sublevel down contains the access to the individual train 
vehicle and to the trackside CAN bus via a serial to CAN converter. 

Each train vehicle PC runs a software program providing a TCP service for 
accessing the individual train vehicle. During startup of the CDS service, it con- 
nects to all train vehicles. The CDS itself is connected via a serial cable to the 
CAN bus of the demonstrator using a serial-to-CAN converter to exchange in- 
formation. During the initialisation, each component (train vehicle and trackside 
elements) is assigned an individual number, by which the models can address it. 
So the CDS service can be seen as a multiplexer/demultiplexer for the different 
data streams from and to the different hardware components of the demonstra- 




Reference Case Study “Traffic Control Systems’ 



109 



application using 
the demonstrator 



abstraction from the 
hardware 

abstraction from each 
element 



direct hardware 
access 




Fig. 7. Communication structure 



tor. This encapsulates and abstracts the different technologies and protocols to 
access individual components from the model level and allows a homogeneous 
access protocol. 

The lowest sublevel contains the direct access to the individual hardware 
items located in the different (physical) components of the demonstrator. 



Communication with the train vehicle. To allow external access, each 
train vehicle is equipped with a PC and a wireless LAN module, which enable 
it to be mobile on the track while being connected to the (wired) LAN of the 
demonstrator. 

On the basis of this technical environment, a daemon (server software) was 
developed to run on the PC of each train vehicle and provide a TCP service 
on standard network equipment for access to the functionality of the train ve- 
hicle. This daemon is also connected to a serial port of the PC where it can 
communicate with the train vehicle control board. 

When an application (in the case study, the CDS is the application using the 
train vehicle) connects to this service, commands can be sent to the daemon, 
which transfers them to the control board where they are processed. In the other 
direction, information sent by the electronic board are received by the daemon 
and transferred to the connected application. This abstracts from the concrete 
hardware implementation of the control board. 

Figure 8 shows a simple information transfer between the CDS service and 
the control board of a train vehicle via the PC on the train vehicle. The first 
part is done via wireless LAN and TCP, the second via the serial line on the 
train vehicle. 



Communication with trackside elements. To access the trackside compo- 
nents of the demonstrator, a cheap and readily available technology had to be 
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CDS service PC on locomotive Control Board 




wireless wired 



Fig. 8. Information transfer between CDS service and a control board of one train 
vehicle 



chosen. In first trials, a self-developed field bus system was used [SS]. A short time 
later, very small and quite cheap microcontrollers with built-in CAN interfaces 
became available, so the decision was made to use this established technology in 
the further development. 

As mentioned above, the CDS is connected to the track’s CAN bus via a 
serial-to-CAN adapter. This allowed us to use a standard PC as CDS with 
no need for a special CAN interface card. This adapter was built using the 
same microcontroller board that was used on the above-mentioned trackside 
components. The CAN data are transferred along the serial line via the serial- 
to-CAN adapter using a transfer protocol which was developed for this purpose. 
It has a simple handshake mechanism, error checking and encapsulates CAN 
messages in single data frames. 

For the CAN bus, a set of messages was defined to transfer commands to 
each specific component (e.g. a barrier or a traffic light of a level crossing), and 
states as replies from the components. 

Figure 9 shows an example of a communication between the CDS service and 
a trackside component. 

3.4 Integration of the Control Algorithm Model 

In order to realize the coupling of the user control algorithm models with the 
demonstrator, an interface definition containing 22 data telegrams has been spec- 
ified (Figure 10 and Table 1). According to the reference case study the control 
algorithm model can be dedicated to three functional parts: the train-borne con- 
trol system, the level crossing control system and the operation centre. These 
functional parts can be developed as a single model or as a three separate models. 

On the middleware level, an API (application programming interface) speci- 
fication is available in order to establish an on-line connection between different 
software tools using a special ITC (Inter Tool Communication) framework. For 
this purpose a tool EXITE [EX] was used, working on the basis of the CORBA 
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Fig. 9. Communication between CDS service and a trackside component 




Fig. 10. Interface for the control algorithm model integration 



standard technology. EXITE provides a server and a client for each connection. 
It follows an object-oriented philosophy, where a client and a server are software 
tasks that can run on any operating system for which a CORBA implementa- 
tion exists. Via CORBA the simulation clients communicate directly with each 
other, thus avoiding any bottlenecks caused by a central simulation member. 
This allows communication via continuous and discrete signals. The simulation 
data are exchanged directly between the client and the server interface. 

In order to test the experimental and the basic demonstrator functions, a con- 
trol algorithm model was designed using the formal Stateflow language (provided 
as well by MATLAB/Simulink®). Figure 11 shows as an example the control 
algorithm model of the level crossing control system. The Stateflow language 
used is equivalent to the finite state machine notation. 
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Fig. 11. Stateflow model of the level crossing control algorithm 
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Table 1 . Telegrams used at the model level for the control algorithm interface 



AmS 


request for manual closing 


LzSt 


traffic light failure 


AO 


activating point 


PG 


position and actual speed of vehicle 


AStM 


display of crossing failure 


Q 


acknowledgement 


EB 


activation order 


QmS 


acknowledgement for manual closing 


EM 


final position report 


Res 


reset 


EO 


positioning system report 


SA 


status request 


FA 


moving authority request 


SM 


status report 


FE 


moving authority 


Sch 


barrier control 


FS 


vehicle sensor 


StM 


failure report 


FsSt 


vehicle sensor failure 


WGU 


speeding warning 


Lz 


traffic light control 


ZBr 


automatic brake activation 



CORBA 



Control algorithm model 

(Matlab/Simulink®) 



ExITE 

Block 



User computer 



Experimenting and basic 
function model 

(Matlab/Simulink®) 



ExITE 

Block 



Demonstrator computer 



Fig. 12. The concept of inter-tool communication in MATLAB/Simulink® 



Inter tool coupling. Application of the tool EXITE allows, in the first in- 
stance, coupling of the control algorithm model on the level of two identical tools 
running on the demonstrator computer and on the (remote) user computer. This 
configuration was applied by integration of control algorithm models designed 
in MATLAB/Simulink® (test purposes) with the MATL AB/Simulink® imple- 
mentation of the experimental and basic demonstrator functions (Figure 12). 
For this purpose EXITE provides a block set allowing a direct implementation 
in the MATT AB/Sim u link® models. 

Similar to its coupling with a MATL AB/Simulink® control algorithm model, 
EXITE supports model integration in several other tool environments (Artisan, 
Rhapsody etc. [EX]). 

In the case of an integration control algorithm model not designed in one of 
the tools supported by EXITE, an additional interface interpreter can be used. 
The interface interpreter provides a connection between EXITE and the appli- 
cation programming interface (API) of the connected tool (Figure 13). This 
solution was applied within the research programme by the coupling of the 
STATEMATE [HL+] models in project USE [BBDKWW] . 



CH — H code coupling. One of the user requirements was to provide the ability 
to validate code generated from a formal control algorithm model. The inte- 
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Fig. 13. The concept of possible configurations for on-line simulation with different 
tools 




Fig. 14. The concept of possible configurations off-line code generation 



gration is realised by a special C++ API class of the demonstrator that can be 
implemented in the automatically generated code. Figure 14 shows schematically 
the coupling of a C++ code generated by a formal specification tool. Within the 
research programme this solution was applied in the case of the tool StP (Soft- 
ware through Pictures) [St] in the project SafeRail [ABG]. 



Remote control algorithm integration. The design of the control algorithm 
integration presented here theoretically allows remote operation of the user com- 
puter. Practical experiences show that the real time requirements of the model 
control system limit the distance to several kilometres. For this reason, a local 
positioning of the user computer seems to be necessary. 

The remote control algorithm integration allows the users to transfer a for- 
mal control algorithm model to the user computer (positioned locally in the 
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demonstrator area) via the internet. The corresponding formal specification tool 
must be installed on the user computer. Using the internet interface of the ex- 
perimental functions (Figure 15) and a remote session with the user computer, 
it is possible to perform the experiment. The visualization and the experiment 
log are the basis for a final evaluation of the control algorithm validation. 




Fig. 15. Remote visualization of the experiment by static and mobile video cameras 



3.5 Experiences with Formal Specification Validation 

During the design of the control algorithm model for testing purposes, several 
imprecise wordings were already identified in the text version of the reference 
case study. As an example, the necessity for “level crossing re-initialisation” was 
discovered in the situation after remedying of a barrier failure. In this context 
the reference case study was refined and updated. 

The final fault-free operation of the railway model device confirmed a cor- 
rect implementation of the defined demonstrator functions. During the testing 
phase regular mode and failure mode operation were checked with regard to the 
possible scenarios (Figure 16 shows an example). The validation experiments 
currently being carried out by the project partners of the research programme 
will demonstrate how the system fulfills user requirements. 

4 Conclusions 

A comparative reference case study has been presented that combines different 
aspects of specification problems from the traffic control systems domain. Do- 
main modelling has been identified as an important field where software spec- 
ification techniques may be applied for integration. It has been argued that, 
besides formal correctness, other notions of correctness are relevant for validat- 
ing a specification, design or implementation. 
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Fig. 16. Example of validation process: the locomotive waits for manual closing of a 
defective barrier 



A physical railway demonstrator model seems to be a suitable means to depict 
all aspects of real operational system behaviour required for software validation. 
The realization of the operational process is a very complex task. It requires a 
true reproduction of all hardware and software components involved as well as 
the modelling of non-deterministic environment influences like human behaviour 
and equipment failures. 

A further important aspect is the integration of the validated software speci- 
fication. On one hand, the presented railway demonstrator offers an opportunity 
to validate a specification in the form of formal models, providing a coupling with 
the respective development tool. On the other hand, it supports the integration 
of C-code, e.g. automatically generated from the formal specification. 

Last, but not least, the capabilities of remote experiment configuration, con- 
trol, visualisation and evaluation make it possible to implement experiments 
without being bound to a specific location. The designed access by internet will 
allow a broad utilisation for scientific and educational purposes. 
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Abstract. For developing precise system definitions and for simplifying the 
evidence of safety, the use of formal methods is highly recommended in the 
new European CENELEC standards for safe railway systems (EN 50126, EN 
50128, DIN EN 61508). But not only in railway sector these methods are diffi- 
cult to handle and to understand. This contribution introduces a concept for de- 
veloping precise system definitions based on a notation, which does justice to 
engineers. A system definition in notation of the Unified Modeling Language 
(UML) is presented for the reference case study single-track level crossing in 
radio-based operation. On the basis of this system definition, relevant safety 
requirements are stated. These safety requirements form the basis for formal 
checks of the system definition for correctness and safety. A precondition for 
formal checks is that the safety requirements are specified in a logic language. 
For that purpose the safety pattern concept is presented, which supports and 
guides the user in selecting and instantiating the correct formal specification of 
safety requirements. 

Keywords: object orientation, UML, safety requirements specification, safety 
patterns, level crossing, radio-based train control system (FFB) 



1 Introduction 

Guidance and safety systems of railways are usually very complex. Due to the use of 
computer systems work done by man is now more frequently being conducted by 
technical facilities. With regards to the means of safety there evolve special demands 
because of new CENELEC standards (cf. [11], [12] and [13]), the computing tech- 
nology and the process of approval. 
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The development of railway systems starts with the creation of a system require- 
ments specification which is the starting-point for the realization / implementation of 
a system. The system definition of a safety related signaling system requires the as- 
surance of the safety authority. By giving its consent, the safety authority confirms 
that the system definition is in accordance with the relevant laws and regulations and 
that it meets the necessary safety criteria. 

Today, system requirements specifications, including those for safety related sys- 
tems, are mostly written in natural language and completed by diagrams e.g. system 
requirements specification of the radio-based train control system (FFB) (cf. [1]), 
which has been the basis for the reference case study (cf. [19]). These are usually 
easy to comprehend but only with difficulty and enormous efforts can they be tested 
as to their consistency, unambiguousness, safety conformity and completeness. In this 
case the new CENELEC standards recommend formal methods but without giving 
concrete and practical instructions of how to do it. What is needed are method-based 
means of description. On the one hand these have to be formal and on the other hand 
they have to be adequate for describing the properties of railway signaling systems. A 
fundamental property of the railway system as such is that it is possible to regard its 
parts as objects. From these objects then new and more specialized objects can be 
derived (e.g. track warrant element -> switch or level crossing; level crossing {single- 
track} -> multi-track level crossing; railway vehicle locomotive -> shunting locomo- 
tive) and some of them can communicate with each other. This leads to the obvious 
conclusion of using an object-oriented approach for specifying those systems, thus 
implying object-oriented means of description. UML then was the choice. Its means 
of description are based on graphics and are easy to understand, thereby meeting 
another requirement from the engineer’s point of view. The UML description tools 
however are for the most part semi-formal. If in a certain range of application the 
necessity arises then a proper formal back-up has to follow so that necessary steps of 
verifying the safety become valid. 

Summarized below are the fundamental demands on the methods: 

possibility of presenting different views of the system 
modularity and compositionality, ability to trace the steps so far con- 
ducted in the system and to identify single modules 
ability of reuse and application throughout the whole development and 
approval process 

integration of formal verification into the method 

ability to validate and carry out a simulation of the system to be built 

easier integration of changes 

for the railway engineers easy to learn, work with and understand 
the description has to be easily comprehensible to the safety authority 
during the approval process necessary with railway systems (proof of 
safety) 

interface for risk and endangering analysis (cf. [9]) 
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Formal methods do raise the precision of a system definition but they are usually 
hard to comprehend and work with not only for engineers. Moreover, formal methods 
do not really support easy implementation of changes and the use throughout the 
whole development process is not that easy. So far this has been the reason why for- 
mal methods have not yet come into use regarding development and approval process 
of railway systems worth mentioning. 

In the first part of this paper we present the construction of the case study transpor- 
tation domain based on the object-oriented paradigm. Since the Unified Modeling 
Language (UML) is on its way to become a standard among the object-oriented speci- 
fication languages we will use UML description means for the system specification. 
The object-oriented approach offers the possibility to project a system and its charac- 
teristics onto a model. The system components can be defined as objects or classes of 
the model. The relationships between these objects then depict the relationships be- 
tween the system components. The object oriented model precisely, compactly and 
comprehensibly represents the static structure and dynamical behavior of the system. 
Moreover, all system implications can be followed by looking at the relations of the 
object-oriented approach (cf. [3] and [5]). Transforming the system components into 
objects represents the point of view of engineers and it yields easier implementation 
of changes. Due to the selected notations of UML being reusable and consistent this 
kind of system definition can be used in subsequent development phases. 

Another advantage of this model is the ability to transform it into a formally verifi- 
able form (cf. [2]) and by employing model checking it can be verified that safety 
requirements are met. Consequently, a formal verification can already be conducted 
during the definition phase. 

The advantage of model checking is its easy use since the formal proof is con- 
ducted automatically. However, the implementation assumes the existence of an ade- 
quate formal specification of the safety requirements which has to be in the form of 
temporal logic. The second part of this paper is concerned with the safety require- 
ments and their shaping regarding the implementation of a formal verification. 

The formal notation of safety requirements as temporal logic formula is difficult 
and prone to errors (cf. [20]). In order to reduce the possibility of errors when formu- 
lating in temporal logic and thereby to make formal formulations of safety require- 
ments easier the concept of safety patterns was developed. With the help of safety 
patterns the transition from descriptions of safety requirements in natural language to 
formulations in temporal logic is demonstrated. This transition is necessary for the 
implementation of the formal verification by means of model checking. 



2 Precise System Definition of the Case Study with UML 

The system definition of the reference case study single-track level crossing in radio- 
based operation is based on the object oriented paradigm. The system is grasped as a 
set of interacting objects. Every object is identified by a name and possesses attributes 
and functions, which are called actions. The data of an object are determined by the 
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attribute values. The object dynamic consists of attribute value changes, which takes 
place in form of action execution. 

For specification of the reference case study, an object oriented model has been 
created (cf. [4]). It depicts the system structure and the dynamic system behavior. The 
system components are considered as interacting objects. The static system structure 
is defined by relations between objects. The dynamic system behavior is described by 
the local behavior of single objects and by interactions between the objects. 

The creation of the object oriented model depends on a procedure, which is de- 
scribed in the next sections. It is also discussed how the requirements of the reference 
case study has been depicted in the model. The model is presented in notation of the 
Unified Modeling Language (UML), which is explained in detail in [28]. 



2.1 Object Oriented Modeling of the Reference Case Study 

The object oriented model of the case study consists of 17 classes. These depict the 
main components of the FFB and their elements. Communication between objects of 
the classes is event triggered. It takes place by action calls of the respective objects. 
Time and observing time related actions and events have been modeled explicitly by 
communication with the object Timer. In this model, the system structure consists of 
class diagrams. These diagrams describe the order of classes of the whole system and 
their relations. 

For every class a state diagram has been created, which represents the local behav- 
ior of objects of this class. The behavior of objects in the faultless case as well as in 
fault cases is modeled in the corresponding state diagrams. Interactions between ob- 
jects have been outlined with sequence diagrams. Always one sequence diagram has 
been created for faultless case and several diagrams for fault cases. Because these 
scenarios are system requirements, they are partly safety requirements, which are 
relevant for formal verification of correctness. 



2.2 Creation of the Object Oriented Model 

Forming the model takes place by identification and depiction of the components, 
their tasks and their relations among each other. The main components of FFB are 
radio block center (RBC), trains and state variable track elements. These communi- 
cate with each other via radio. Operation handling follows by peripheral track protec- 
tion and control, train speed supervision and train separation. These tasks are realized 
by cooperation of system components. Every component executes a set of actions, 
which in cooperation with actions of other components lead to fulfillment of the in- 
tended tasks. The specification of the system structure results from identification of 
system components and their relations. Specification of the system behavior consists 
in action descriptions of the several components and their chronological order in the 
whole system. 
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2.3 System Structure 

When creating the model of the reference case study the three components RBC, 
trains and track elements are the first classes of the model. The attributes and the 
actions of these classes are defined with the help of subtasks of the track protection 
and control, train speed supervision and train separation. A train needs a movement 
authority to accomplish a train run. The beginning and the end of the requested route 
is according to the registration in the route map. RBC is competent for issues of 
movement authority and assignment of tracks. Therefore the actions re- 
quest_movement_authorityO, request_elementQ, etc. are defined in class RBC. Fi- 
nally in class Track Element the actions start _j?rotection(), report_status( ), etc. are 
defined, because the track element has to be protected when requested and has to 
report its status when requested. 

For tasks like refresh_route_map(), distribute _route_map(), etc., which can not be 
allocated to any of the named classes the class Administration is introduced. In addi- 
tion, the class is responsible for putting into operation and putting out of operation of 
all objects. In consequence, there is the system structure of Figure 1. 




Fig. 1 . System structure of FFB 

In addition to state variable track elements there are also balises on routes. Balises 
serve to determine absolute location information. Consequently, a route consists of 
track sections, balises and state variable track elements like e.g. switches and level 
crossings. In Figure 2 the relation between the class Route and its parts is depicted by 
means of aggregation. The relations aggregation and composition are used for depic- 
tion of whole-part relationship among the objects. In UML (cf. [28]) these relations 
are used to describe the case when two or several classes belong together. It is 
claimed, that both kinds of relations define a transitive, non-symmetric relationship. 
Based on the relationship between the behavioral and structural aspects of system 
components we have discussed these relations and their properties in [3]. We have 
shown that aggregation and composition can not be transitive. 
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In FFB elements like level crossings and switches are state variable track elements. 
They are protected on demand and they respond their current status on demand. In 
this paper, it is not dealt with switches and with other kinds of track elements. Every 
state variable track element communicates with trains or with the RBC via radio 
communication modules. In addition, every track element is able to detect defects and 
to report them to the RBC. If a procedure of a track element is not completed in time 
then a defect is assumed. Therefore, every track element possesses a timer. The timers 
are necessary for control and observation of temporal sequences. Consequently, the 
classes Communication Module and Timer are parts of the Track Element. Relation of 
composition shows in the respectively class diagrams, that these classes are parts of 
the class Track Element. 




Fig. 2. Route and its elements 



By using the concept inheritance all properties of the class Track Element are 
transferred to the specialization classes like Level Crossing and Switch. Accordingly, 
there results the class diagram for Track Element and Level Crossing, which is de- 
picted in Figure 3. In addition to the parts Communication Module and Tinier, which 
have been adopted from class Track Element, according to the radio-based train con- 
trol system the class Level Crossing has the special parts Wayside Signal, Barriers 
and Switch Off Sensor. 




Fig. 3. Class diagram of the classes track element and level crossing 
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In the object oriented model of the reference case study the objects of class Train 
have as sub-components objects of the classes Communication Module, Timer, Route 
Map, Odometer , Brakes. An object of class RBC possesses as sub-components objects 
of the classes Communication Module, Timer, Route Map and Route. To an object of 
the class Administration belong objects of the classes Communication Module, Timer 
and Route as components. For these classes there are no figures in this paper. 



2.4 System Dynamics 

System dynamics consists of the internal behavior of several objects and of interac- 
tions between objects. In the object oriented model of the reference case study the 
internal behavior of objects has been specified using UML state diagrams. For de- 
scribing system scenarios, UML sequence diagrams have been used. In the following, 
the behavior of the model is explained by means of the main components level cross- 
ing, RBC and train. 



2.5 Internal Behavior of Objects 

In the reference case study, the task track protection is subject to cooperation between 
RBC, trains and state variable track elements. The train sends in time a request to the 
track element. The track element has to acknowledge the receiving of the order. After 
completing the protection procedure, a status report from the track element is given. 
According to the current state of track element, it has to be decided, if the train is 
allowed to drive on the track element or if it has to stop before entering the track 
element. 

In the system requirements specification of FFB for every track element it is de- 
manded, that it starts automatically the protection procedure. Every track element has 
to acknowledge the receiving of a request and has to react to a status request by 
means of a message on the safe or unsafe state. Track elements have to be able to 
detect defects by permanently executing tests. Defects have to be reported to the 
RBC. A defect track element has to react on a request respectively on a status request 
with a message on its defect status if still possible. Finally, every track element has to 
offer the possibility of manual control because of reasons of availability. As a conse- 
quence the staff is able to operate the track element locally, e.g. if it is defect. The 
requirements on a track element can be specified in form of a general behavior for all 
track elements, see Figure 4. There, t akt stands for the current time. 

A level crossing is a state variable track element. It performs the protection proce- 
dure by setting the wayside signal on red and closing the barriers. Using the concept 
inheritance all properties of the class Track Element are transformed to specialization 
class Level Crossing. Inheritance not only compromises static but also dynamic prop- 
erties. All functionalities, which have been defined as behavior of track elements are 
adopted and if necessary extended for the level crossing. We have discussed in [5] 
this kind of inheritance. We have shown, that the specialization class inherits the 
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Fig. 4. State diagram of class Track Element 



dynamic properties in the context of their states in the state diagram. Therefore the 
specialization class adopts all attributes, actions, states and transitions of the general 
class as well as all relations to other classes. 

The behavior of the objects of class Level Crossing is an extension of the behavior 
of Figure 4. Every time, the objects of this class are in one of the defined state. The 
extension of this behavior corresponds to the activities in the states Free and Process- 
ing_Request and the transitions of these states. All other states and actions remain 
unchanged. In Figure 5 the part of the state diagram of class Level Crossing is pre- 
sented, in which the extended behavior of the mentioned states is depicted. 

In the depicted states the objects of class Level Crossing communicate with its sub- 
components Wayside Signal , Barrier and Switch Off Sensor. The state diagrams of 
these classes are not presented in this paper. 

In the model the RBC is responsible for assignment and administration of tracks, 
track sections and for checking and allocation of the movement authority. It passes 
the messages, which are sent to the RBC in case of fault detection, on the class 
Administration. Figure 6 shows the modeled behavior of class RBC. The objects of 
this class communicate with objects of its sub-components and the objects of the class 
Train. RBC administrates the track sections by comparison of the given movement 
authority and the already released track section by determining the position of the rear 
of the train from the received train location and length of the train. 
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Fig. 5. Extension of the states Free and Processing the Request at level crossing by inheritance 

The abbreviations in Figure 5 have the following meanings: 
ws = wayside signal, barr = barrier, sen = switch off sensor, t G = duration of yel- 
low light, t, = duration of red light before closing the barriers, t mis = minimal dura- 
tion between two protection processes, t s = length of time to close, t 8 = length of 
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time to open barriers, t e = time to activate the level crossing, t atl = current time, t 
= time to return to normally free state of level crossing. After expiration of t , the 
protection procedure is finished by switching of the wayside signal and the barri- 
ers. 

In the model the train communicates with RBC, level crossing (lc) and in addition 
with its own sub-components. The communication with RBC at first consists in re- 
questing the movement authority (ma) and determining the departure time (t a ). After 
departure, the train informs RBC about current location. The location report takes 
place with the interval t m . The location detection is done by communication with the 
sub-component odometer and by passing a balise. The absolute location is received at 
each balise. The relative location between balises is given by communication with 
odometer. Velocity observation takes place by comparing the current velocity (v) 
with the permitted velocity limit (v_limit). The permanent location detection and 
velocity observation are executed in parallel to further activities of the train. These 
processes are started when the brake is released with the action released) and stopped 
after the brakes have been applied and the velocity is zero (v = 0). 




In order to communicate with the level crossing, the train calculates according to 
its current velocity and its current location a point in time (ct) to contact the level 
crossing. After sending the request, the maximum time for acknowledge receiving (t q ) 
is calculated. In case of successful protection of the level crossing, the train passes the 
level crossing and identifies the next hazard point. This might be another level cross- 
ing or the endpoint of the movement authority. If the level crossing is defect, then the 
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Fig. 7. State diagram of class Train 
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protection has to be done manually after stopping of the train before the level cross- 
ing. The manual control is realized by the action operate_local{). After passing the 
level crossing, it is reset in stat e Automatic operation. 

Figure 7 shows the dynamic behaviour of the train. In addition to the already men- 
tioned abbreviations there are the following ones: lc stands for level crossing, rm for 
route map, odo for odometer, com for communication module and brk means brake. 



2.6 System Scenarios 

The operation scenarios, which are depicted in [19] can be modeled in form of inter- 
actions between the system components. A train run starts, after the train requests the 
movement authority from RBC for a route and if the route is free the movement au- 
thority has been assigned. If there is a level crossing on the route then the train sends 
a request to the level crossing. The level crossing has the task to protect itself. The 
train is only allowed to pass the level crossing if it has received the message of the 
protected level crossing. After the train has passed the level crossing, the protection 
process is finished. 

| RBC | | Train | | Level Crossing 




Fig. 8. System scenario of the defect-free case 

In Figure 8 this scenario is depicted with the objects RBC, train and level crossing. 
Movement authority is abbreviated with “ma”. The point in time, in which the train 
contacts the level crossing in order to send request is abbreviated “ct”. This scenario 
describes the defect-free case, in which neither there is a defect or delay of the train 
nor a defect of the level crossing and its parts. 

If the train does not receive the message of the protected state of the level crossing 
as a consequence of a failure, then the train has to stop before the level crossing. In 
this case the level crossing has to be protected manually by the staff. After the train 
has passed the level crossing, then the train is turned back in automatic operation. 
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This case may happen, if the protected state is not reached because of a failure of the 
level crossing or of one of its parts. Another possible reason is a failure of a commu- 
nication module, which cuts off the radio contact between train and level crossing so 
that the level crossing does not receive the request or does not send the acknowl- 
edgement. For all these cases, a separate sequence diagram is necessary. Exemplarily 
a scenario is depicted in Figure 9. In this case, the level crossing is defect but the 
communication between train and level crossing takes place. 



RBC 



Train 



| Level Crossing ] 



request_ma () 



[route free] send_ma () 



I set_ct () 

Fakt = ct] request_lc () 



[defect] report_state (defect) 
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IP [v = 0] operate_local () 
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exit () 



c 



[location = lc. location + 
train_length] brake () 

[v = 0] operate_autom () 



Fig. 9. System scenario with defect level crossing 



3 Specification of Safety Requirements 

For evidence of safe functionality the safety related correctness of the system defini- 
tion has to be shown. For that purpose the compliance of safety requirements in the 
UML model has to be checked. To perform this correctness check sound and to in- 
crease trust in the system definition as basis for the development of a safe system, the 
correctness check should be done with formal exactness. On that score the safety 
requirements have to be specified formally as basis for formal correctness checks. 
This section of the paper handles the specification of safety requirements with regard 
to formal verification of the UML system definition. The concept has been developed 
in order to avoid mistakes in formal formulations of safety requirements and conse- 
quently to simplify formal specification. By means of safety requirements of the ref- 
erence case study, it is explained how descriptions of safety requirements in natural 
language can be systematically transformed to formal specifications by using safety 
patterns. 
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3.1 Preparation of the Safety Requirements 

In order to achieve sensible results of practical relevance for evidence of safe func- 
tionality, it is important to derive systematically the safety requirements. There is the 
problem that safety requirements, which have been formulated independently of the 
creation of the system model, are too abstract for direct formalization and formal 
verification. This is a further obstacle in the widespread use of formal verification 
methods in engineering. The precondition for formalization is that the safety require- 
ments must have reference to the UML system model, see [6] and [23]. Safety re- 
quirements can be distinguished into two different groups depending on the abstrac- 
tion level: general safety requirements and model specific safety requirements. 

General safety requirements result from accepted rules of engineering and general 
regulations, which are relevant to safety engineering in the railway sector. The basis 
for the identification and informal specification of general safety requirements of the 
case study have been the official system requirements specifications of FFB, the de- 
scription of the case study, railway standards and regulations. The resulting list of 
general safety requirements can be found in [17]. For example: 

A train may only pass a level crossing in automatic operation, if the train has re- 
ceived the message on the orderly protection of the level crossing. 

What it does mean “orderly protection” is not stated. While general safety re- 
quirements are extensively independent of a specific solution, model specific safety 
requirements are formulated in context to a specific technical solution concept. They 
consider details of the system. Furthermore, model specific safety requirements deal 
with single system details while general safety requirements regularly affect different 
aspects. So, one general safety requirement can have several corresponding model 
specific safety requirements. Model specific safety requirements are specified in con- 
text to a model of the system. Variables of the system model (state, event, action, 
condition or any other attribute variables) are used in the formulations of model spe- 
cific safety requirements. By using safety analysis techniques, especially FMEA, the 
formulation of safety requirements in context to the UML system definition is sup- 
ported (cf. [6] and [9] for more details). In these analyses, possible failures of system 
functions and its correlation are analyzed, which lead to operational hazards. The 
general safety requirements have to be considered. In order to prevent systematic 
failures, which have been detected in the analyses, safety requirements are formulated 
for these system details. In order to achieve, that these safety requirements are model 
specific, the safety analyses have to be performed in context to the UML system 
model. Then the model structure and model variables are used in the safety analyses. 
In [16] it is described how the system structure with the system functions can be 
automatically derived from the UML system definition. In this way not only effi- 
ciency of system development is increased but also FMEA is performed consistent to 
the UML system definition. 

Relating to the general safety requirement example it can be analyzed in the 
LMEA which failures could avoid an orderly protection. In Figure 10 an FMEA detail 
is shown, which is based on the system definition (cf. Figure 1 and 3). One detected 
failure function is “switch on barriers is too early”. If the barriers are closed too early 
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it could happen that the time is too short to vacate the level crossing. To prevent this 
operational hazard, which arises from the detected safety relevant failure function the 
following model specific safety requirement is defined: 

Level_Crossing.switch_on_barr is only permitted to be valid when the time 
Level_Crossing.t , after occurence of Wayside_Signal.switch_on_red_light has 
been run down. 

This model specific safety requirement is specified as relation between the model 
variables “ switch _on_barr ” of the class “ LeveljCrossing ” (cf. Figure 3 and 5), the 
duration of red light before closing the barriers “tf of the class “ LeveljCrossing ” (cf. 
Figure 5) and the variable “switch_on_red_lighf’ of the class “Way side -Signal” (cf. 
Figure 3). 



compound system system component system function failure function 




Fig. 10. Detail of FMEA as basis for derivation of model specific safety requirements 



3.2 Difficulties of Specifying Safety Requirements Formally 

A precondition for formal correctness checks of safe functionality by model checking 
is the specification of safety requirements in temporal logic. Details on temporal logic 
can be found in [8]. One reason for the very rare use of model checking is the diffi- 
culty of understanding and applying temporal logic, especially for engineers, who are 
normally not familiar with higher logic. In [21] it is reported from the case study of 
[14] on model checking, wherein not only model failures are detected but also errors 
in the formally stated requirements in temporal logic. It is concluded in [20]: “Ex- 
pressing certain properties in temporal logic is complex and error-prone, not only for 
practitioners but for formal methods experts as well.” In [8] the difficulties are dem- 
onstrated to correctly read, interpret and formulate requirements in temporal logic. 
The difficulty lies in the correct use of the complex semantics of temporal logic with 
its very expressive power. It easily happens, that a formula is specified, which states 
something different than it really should. The consequences could be fatal in such a 
way that the system is unsafe only due to problems related to formal specification. 

In the standards DIN EN 61508 [15] and EN 50128 [11] these difficulties have 
been recognized. For reasons of clarity, in addition to formal specification, the use of 
a natural language is necessarily required. But this is not a sufficient solution. The 
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problem is that a natural language permits ambiguous formulations. Therefore a pos- 
sible consequence could be a specified safety requirement, which is interpreted dif- 
ferently with respect to the original intention of the formal specification. Moreover, 
an equivalent specification of the original intention cannot be guaranteed. A solution 
to solve these problems of applicable precise specification and interpretation and of 
specification in a natural language terminology equivalent to formal specification is 
the safety pattern concept. This is explained in detail in the next section. 



3.3 Safety Patterns Concept - The Key to Formal Specification of the Safety 
Requirements 

The core idea of the safety pattern concept is to formalize safety requirements with 
the help of a finite set of specification patterns. These patterns contain only those 
temporal logic expressions, which are suitable for the different kinds of safety re- 
quirements. Because these patterns are used for the specification of safety require- 
ments, they are called safety patterns. For conventional specifications of safety re- 
quirements, which have to be formalized the system developers select the suitable 
specification patterns from the catalogue of safety patterns (cf. Figure 1 1). In a further 
step, the selected generic formulations are instantiated with the result of the instanti- 
ated formulation of the safety requirement. These steps of formalization are tool sup- 
ported and are explained in section 3.4. 
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Fig. 11. Overview on the safety pattern concept 



In the catalogue, the safety patterns are classified in such a way that every safety 
pattern has a specific and a clear classification, which enables a definite identification 
of the safety patterns. Every safety pattern can be found in the formal notations CTL 
(Computation Tree Logic), LTL (Linear Time Temporal Logic) and p-Calculus. In 
this way the developer can choose the formalism required for the verification tool 
according to his preferences. Every safety pattern is explained in natural language, so 
that the meaning of the safety patterns is easily understood. 
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As explained earlier, standards necessarily require for reasons of clarity that in 
case of formal specification there should be also a formulation in a natural language. 
For that reason, safety patterns do not only support formal specification of safety 
requirements but also enable specifications in the terminology of a natural language 
equivalent to the formal specification. Every safety pattern contains a specification 
template in a restricted terminology of natural language. The meanings of the allowed 
structure and terms used for description are fixed, see [7], This means that a norm 
language for safety patterns is used. A norm language sounds similar to a natural 
language, but it is a strongly reduced form of a natural language. It is a connecting 
link between natural languages and formal languages [24]. By the fixed assignment of 
a formal formulation and a formulation in restricted safety requirements related ter- 
minology, the equivalence of formal specification and specification in words of natu- 
ral language is guaranteed. The demands of the standards are fulfilled and simultane- 
ously the weakness of the standards is resolved. In this manner, a safety pattern can 
also be used to formulate precisely a safety requirement in natural language. Finally, 
every safety pattern contains an example of use. Figure 12 shows exemplary a safety 
pattern. 

It is also in progress to enlarge the data in every safety pattern with graphical de- 
scriptions. The graphical description contains typical possible sequences of states and 
also different examples of possible computation paths, see [7], 

In teamwork communication and also in communication with approval authorities, 
the meaning of formal safety requirements is to interpret clearly based on such a 
safety pattern catalogue. 

[9] states the role and the benefits of embedding the safety pattern concept in the 
process of developing system requirements specifications for railway systems. 



3.4 Tool Support for the Selection and Instantiation of Safety Patterns 

For developers using the safety pattern concept it would be very hard to select suit- 
able safety patterns only on the basis of a list of safety patterns. To have an overview 
on the different kinds of classification criteria and of the respective classes, tool sup- 
port is necessary, which assists in the selection of the correct safety patterns. Fur- 
thermore, the software tool guides the system developers at the instantiation of ge- 
neric formulations to avoid mistakes in this specification step. The tool name is 
SAPIS ( Safety Pattern Instantiation System). It is a web-based application, which can 
be used via the Internet at http://www.ias.uni-stuttgart.de/safety-patterns/. 

The safety patterns are catalogued by means of 13 classification criteria. Every 
classification criterion is decisive for the classification of a safety pattern to one of 
two or more classes. E.g. one criterion is the temporal restriction of validity. The 
possible classes are duration of validity, beginning of validity or beginning and 
duration of validity. A certain combination of classes of different classification crite- 
ria describes the different properties of a safety pattern. 
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Safety Pattern ds-woet-nv-84 

Dynamic safety requirement without explicit time, concerning beginning and duration 
of validity and concerning necessity of validity, safety pattern ID 84 

Generic Formulation in Norm Language 

If a is valid then b must be valid permanently until c is valid. 

Generic Formulation in Formal Languages 

CTL: AG (a -> A(b W (c and b ) ) ) 

LTL: G (a -> (b W (c and b ) ) ) 

g-Calculus: nu Zl. ( (a -> nu ZO. ( (c and b) or 
(b and [-] ZO) ) ) and [-] Zl) 

Explanation in Natural Language 

A main characteristic of this safety pattern is that b has to be true always from this 
point in time on when a is valid. This has to be valid every time when a occurs. Then 
b must be permanently valid until c occurs. There must be no interruption in the va- 
lidity of b until c occurs. The validity of b must neither end anytime before c nor in 
the state directly before c but may end first in this state when c becomes true, a as 
well as c may occur but they do not have to. 

Example of Use 
System 

Level crossing in radio-based operation 
Conventional specification of the safety requirement 

If the messages Level_Crossing . report_defec t ( wayside_signal ) or 
Level_Crossing . report_defect (barrier) are true, then 
Level_Crossing . acknowledge = 0 must be true until Level_ Cross- 
ing . repare occurs. 

Safety requirement in norm language 

If Level_Crossing . send_defect (wayside_signal) or 
Level_Crossing . send_defect (barrier) is valid then from this point in time 
on Level_Crossing . acknowledge = 0 must be valid permanently until 
Level_Crossing . repare is valid. 

Safety requirement informal language (CTL) 

AG ( (Level_Crossing . send_defect (wayside_signal ) or Level_ 
Crossing . send_defect (barrier) ) -> A ( (Level_ 

Crossing . acknowledge = 0) W [Level_Crossing . repair and 
(Level_Crossing . acknowledge = 0) ) ) ) 



Fig. 12. Safety pattern example 

Based on this safety patterns classification scheme, it is possible to select the ap- 
propriate safety pattern for the safety requirement to be specified. Every classification 
criterion can be used to characterize a property of the safety requirement to be speci- 
fied. In this way, the properties of the searched safety pattern are selected and so the 
searched safety pattern itself is selected. This selection process is tool supported by 
SAPIS [8]. With the help of the dialog system of SAPIS the system developer selects 
the suitable safety pattern classes step by step in the form of question-answer- 
interactions. SAPIS helps to determine, which criteria are relevant for the safety re- 
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quirement to be specified. It also supports the user to make decisions in a meaningful 
sequential order. The precondition to avoid specification faults by using SAPIS is the 
correct comprehension of the safety pattern classes. 

SAPIS offers built in search functions enabling one to refer to the exact meaning 
of safety requirement specifications. 

The safety pattern tool set also contains graphical simulations in the form of Java 
applets to support correct interpretation of safety patterns. As a simulation concept 
the intuitive interpretable representation of timing diagrams is used (cf. [7]). Every 
safety pattern has at least one condition variable and one property variable. The prop- 
erty variable depends on the condition variable. The simulation concept is an interac- 
tive dynamic visualization in such a manner that the user is able to set step by step 
any value successions of the conditional variable whereas the value of the property 
variable is simulated by the tool. With the use of colors, a visual distinction is made 
between “possible validity”, “deterministic validity” and “undefined validity”. There 
is also a visualization feature for compositions of safety patterns. In this way, incon- 
sistencies between formulations can be revealed. 

With the help of the instantiation assistant of SAPIS mistakes at instantiation can 
be avoided. For that purpose, it is checked that the user only uses variables, which 
have been previously declared. The tool supports the insertion of single system vari- 
ables, propositional compositions of system variables (by not, and, or, — ») and 
connectives of comparison (>, <, =, A). The correct syntax related to the used variable 
types is checked. The tool supports the specification of complex safety requirements 
and the storage and the management of instantiated safety requirements. For specifi- 
cation of complex safety requirements several safety patterns have to be combined by 
and, or or not connectives of propositional logic. In other cases, safety patterns 
have to be inserted in other safety patterns to specify complex safety requirements, 
see [8]. In some cases it is also necessary to insert value changes of a variable (e.g. 
the entrance in or exit of a state; removing signal), which is supported by SAPIS, see 
[ 8 ]. 

3.5 Derivation of the Safety Pattern Set 

A major objective, the safety pattern set has to accomplish, is that all possible safety 
requirements for automation systems like train control systems have to be specifiable. 
According to [22, p. 181] and [18] automation systems like traffic control systems are 
reactive systems. Properties of reactive systems can be specified in temporal logic, 
see [25]. Safety requirements are the safety relevant subset of the expression 
possibilities of temporal logic. 

Consequently, the specification of temporal relations plays a particular role in the 
properties of automation systems. Such systems underlie the temporal behavior of the 
technical process, which is the technical environment in which the automation system 
operates. Therefore the formulation of temporal relations in requirements of automa- 
tion systems plays an essential role. Consequently, the safety pattern concept has to 
support the correct specification of such temporal relations in safety requirements 
with regard to formal correctness checks of system models. 
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To fulfill this demand the safety pattern set has been derived according to the fol- 
lowing steps: 

1. The set of necessary generic formulations for safety patterns is derived: 

It is taken into consideration, which atomic syntactical formulation possibili- 
ties exist in the common temporal logic languages LTL and CTL. Logic expres- 
sions which result from basic combinations of temporal logic operators and 
which are repeated in complex formulations are considered as atomic. Addition- 
ally, only those formulations are taken into account, which possess a meaning, 
which has not yet occurred in the analysis of expression possibilities. According 
to [26] and [27] the different linguistic layers at sentence level and at meaning 
level need to be distinguished. This means, that there can be several formulations, 
which are different at sentence level but which are equal at meaning level. There- 
fore, in our consideration there are different expressions in temporal logic at sen- 
tence level, which are equivalent at meaning level. In the analysis of expression 
possibilities of temporal logic, only expressions, which have not yet been taken 
into account in the set from the meaning level point of view, are included in the 
set of necessary generic formulations. 

Another part of this analysis is to check whether the considered expressions 
are meaningful in context to safety in terminology of automation. This implies, 
that safety means avoidance of danger, cf. [10]. For that purpose, only formula- 
tions are suitable for safety requirements, which express a deterministic relation 
of system variables and which clearly define under which conditions the ex- 
pressed property has to be valid. Other formulations tolerate undefined behavior 
which could lead to hazardous system situations. E.g., the CTL formula (1) is not 
relevant for safety requirements. 

AF (p -> AX EF q) (1) 

The meaning is that anytime a system state has to be reached in which is valid: 
If p is true, then anytime later q has to be reachable. Thereby not in all but only 
in some states it has to be true, that if p is true then at anytime later it must be 
possible that q is true. It is not controlled at which points in time this demand has 
to be true. It is absolute arbitrary when the attainability property is valid. This 
non-determinism is not tolerable from the safety point of view. 

The analysis result is a set of 32 expressions in temporal logic, which form the 
set of necessary generic formulations for safety patterns. This set is the basis for 
specifying all safety requirements by composition and instantiation. E.g. “p must 
be permanently valid, before q is valid, and must only be valid, before q is valid” 
can be expressed by the formulations (2) and (3) and a logical AND- 
composition. The resulting meaning is “p must be permanently valid, before q is 
valid”, and “from this point in time on when q is true p must never be valid”. 

A (p W q) (2) 



AG ( q -> AG (not p) ) 



(3) 
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2. The set of useful generic formulations for safety patterns is derived: 

This set supports the usability of the safety pattern concept. Firstly, for the 
purpose of usability the set of necessary generic formulations is analyzed with 
regard to distinct characteristics of the different generic formulations so that the 
formulations can be classified. Classification is necessary to select the appropri- 
ate generic formulations for the safety requirements to be specified. The sensible 
organization of the safety pattern set by classification criteria and safety pattern 
classes leads to additional generic formulations, which could also be created by 
the combination of basic formulations. 

From former experiences with specification difficulties, further safety pattern 
classes have been added, so that the safety pattern set also contains further non- 
atomic generic formulations. Such specification problems are caused by: 

■ non-trivial compositions of safety patterns. 

■ decisive specification possibilities which are likely to be overlooked. For 
this reason, rather than using compositions these cases should be part of 
the safety pattern catalogue. 

■ specification problems relevant for automation, which are not supported 
by dedicated language constructs, e.g. safety requirements with explicit 
time. 

As result of this, 13 classification criteria have been identified. The combina- 
tion of these safety pattern classes produces a set of 454 safety patterns. To pre- 
vent the safety pattern set from getting too large in order to keep the selection 
process simple, a safety pattern can also contain special cases. They contain ge- 
neric formulations with minor differences the regular generic formulations. 



3.6 Example of Safety Requirements Specification with the Help of Safety 
Patterns 

The application of SAPIS will be demonstrated by a brief example. For the safety 
requirement of the reference case study there is the following model specific safety 
requirement: 

If the class “Train” is in state “Passing” while class “LeveljCrossing” is in state 
“ Automatic ^Operation” , then at the same time class “Barrier" has to be in state 
“Barrier_Closed”. 

The property that class Barrier is in state Barrier jClosed has to be true under cer- 
tain circumstances. The condition is that class Train (cf. Figure 1) is in state Passing 
and class LeveljCrossing is in state Automatic _Ope ration (cf. Figures 3 and 4). It is 
easy to formalize this condition with the help of a logical and: 
(Level_Crossing . state = Automatic_Operation) and (Train. state = 
Passing) . But to express the validity of the property depending on this condition, a 
suitable safety pattern has to be selected. To detect the suitable formal specification in 
the temporal logic CTL, first the safety requirement has to be assigned to the correct 
classes of the different classification criteria with the help of SAPIS. In the following 
the relevant classification criteria, which have to be decided are listed (a) along with 
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the related decision making questions belonging to them (b). Then the decision re- 
garding the correct class the safety requirement belongs to is explained (c). Unlike 
SAP1S not all decision possibilities are listed here because of lack of space. 

1. a. Existence of a temporal logic aspect in the safety requirement. 

b. Does the safety requirement contain any temporal logic aspect? 

c. Yes, the property has to be true only at certain points in time. It has to be 
valid always then when class Train is in state Passing and class 
Level_Crossing is in state Automatic_Operation. For that purpose, the 
suitable safety pattern class is dynamic safety requirement. 

2. a. Existence of dependencies between propositions. 

b. Should the searched generic formulation contain any logical dependency 
between propositions? 

c. There is a logical dependency between ... 

• ( (Level_Crossing . state = Automatic_Operation) and 
(Train. state = Passing) ) and 

• Barrier . state = Barrier_Closed (cf. Figure 3). 

Therefore, the safety requirement belongs to the class safety requirements 
with dependencies between propositions. 

3. a. Type of time specification. 

b. Does the safety requirement contain any explicit time specification? 

c. No, there is no temporal statement dependent on a system clock. For 

that reason, it is a safety requirement with implicit time specification only. 

4. a. Modality of demand. 

b. What is the modality of demand? 

c. The safety requirement does not state a permitted behavior but 
a necessary one. That is why the class is necessity. 

5. a. Type of validity beginning. 

b. When exactly should the validity of the demanded property begin? 

c. The demanded property has to be valid at once, because the condition is 
non-temporal. In the safety requirement, it is only stated that the property has 
to be true always at those points in time, in which the condition is fulfilled. It 
is not stated when the condition, that class Train is in state Passing and 
class Level_Crossing is in state Automatic_Operation is valid. So the 

class is property with non-temporal condition. 

Based on this classification the following safety pattern with the appropriate ex- 
planations is identified: 

Generic formulation in safety pattern norm language: 

Always if a is valid then also b has to be valid. 

Generic formulation in formal language (CTL): 

AG (a — > b) 
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Specification of the safety requirement in norm language: 

Always if ( (Level_Crossing . state = Automatic_Operation) and 
(Train, state = Passing) ) is valid then also (Barrier . state = Bar- 
rier_Closed) has to be valid. 

Specification of the safety requirement in formal language (CTL): 

AG (( (Level_Crossing . state = Automatic_Operation) and 
(Train. state = Passing) ) -A (Barrier . state = Bar- 
rier_Closed) ) 

The example shows clearly that the variables of a safety pattern predicates can be 
substituted by state, event, action, condition, configuration variables or combinations 
(cf. section 3.4) of the corresponding system model. By using the model checker 
SMV the fulfillment in the system definition (cf. section 2) safety requirements, 
which have been formalized in the depicted way has been shown. 



3.7 Demonstration of Benefits for Applied Concepts 

By means of the demonstrator of the Institute for Traffic Safety and Automation En- 
gineering [19], benefits of the used concepts to achieve evidence of safe functionality 
have been illustrated. It has been demonstrated that the safety requirements, which 
have been checked by model checking are also preserved at control of the demonstra- 
tor. The UML model has been adapted to form the basis for demonstrator control. 
Therefore it has also been demonstrated that the system definition has been precisely 
specified. By the safe operation of the demonstrator it has also been pointed out that 
safety requirements specified with the help of safety patterns have avoided false 
specifications. For that purpose the demonstration possibilities have been used to 
cause safety critical situations by setting hardware failures. In this way the correct 
system behavior can be observed in different safety critical situations. Using the 
demonstrator it has been also illustrated that the use of model checking and the auto- 
matic transformations of the UML model in the entrance language of the model 
checker has been successful. The verified safety requirements are preserved in opera- 
tion of the demonstrator. 

The demonstrator control has been technically realized by a C++ software pro- 
gram. This has been implemented systematically on the basis of the UML model by 
using code generation. For that purpose, the code generator of the tool Software 
through Pictures (StP) from the company Aonix has been applied. This code genera- 
tor allows the specification of the transformation rules in detail. The same kind of 
transformation has been used to convert the UML model into the entrance language 
of the model checker SMV. Data interchange between the control software and the 
software interface of the demonstrator (see [19]) has been manually implemented in 
C++. 
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4 Summary 

By means of the case study single-track level crossing in radio-based operation, a 
way to develop a precise system definition and to obtain evidence of safe functional- 
ity has been depicted. The concept complies with European standards in the railway 
sector and with the generic safety standard DIN EN 61508 [15]. The UML notation 
can be used to specify a precise and clearly understandable system definition, which 
is exact, unambiguous and compact as well as easy to understand by developers, 
operation authorities and supervising authorities. A precise system model in UML 
enables correctness and refutation checks related to the fulfillment of safety require- 
ments. The expenditure for creation of an object oriented system definition is consid- 
erably higher than a description in natural language but it possesses the named bene- 
fits. 

Safety patterns have been introduced as pre-specified safety requirements, which 
convey an expert knowledge on correct specification and interpretation of safety 
requirements. Applying safety patterns, engineers who are no experts in higher logic, 
are able to correctly specify and interpret safety requirements in formal specification 
languages, what is recommended by standards, as well as precise specifications in a 
natural language. In this way, safety patterns are a connecting link between specifica- 
tions in a natural language and formal specifications. The concept helps to comply 
with recommendations and demands of safety standards in specifying safety require- 
ments formally and in describing the formal specification in terms of natural lan- 
guage. Furthermore, it overcomes weaknesses of safety standards. The concept sup- 
ports the correct use of formal languages for specification and interpretation. Ambi- 
guities in using a natural language to describe formal specifications are avoided. The 
equivalence of the formal specification and the specification in norm language is 
guaranteed. 

With the help of the demonstrator the benefits of the developed and used concepts 
has been illustrated. 
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Abstract. In this paper, the authors introduce an extension of UML for 
the purpose of hybrid systems modeling. The construction uses the pro- 
file mechanism of UML 2.0 which is the standard procedure for extending 
the Unified Modeling Language. The “intuitive semantics” of the syntac- 
tic extension is based on the semantics for hierarchic Hybrid Automata, 
as suggested by Alur et. al. In contrast to Alur’s formalism, HybridUML 
allows to label transitions not only with conditions and assignments, but 
also with signals. Furthermore, our approach associates formal seman- 
tics by definition of a transformation from HybridUML specifications 
into programs of a “low-level” language which is both executable in hard 
real-time and semantically well-defined. When compared to approaches 
assigning semantics directly to the high-level constructs of a formal spec- 
ification language, the transformation approach offers two main advan- 
tages: First, semantics can be more easily adapted to syntactic extensions 
by extending the transformation in an appropriate way. Second, all mod- 
els are automatically executable, since the low-level language is. 



1 Introduction 

A real-time system is called hybrid if it processes time- continuous variables in 
addition to discrete-range parameters. The (piecewise) continuous evolution over 
dense time of real or complex observables occurs naturally in physical models 
and in the development of (embedded) control systems monitoring some contin- 
uous observables (e.g. temperature, speed) via analog sensors and setting others 
(e.g. voltage, thrust) using actuators. 

In this paper, the authors introduce HybridUML , a novel specification for- 
malism for hybrid systems, and the Hybrid Low-Level Language Framework HL 3 
for generating programs to be executed in hard real-time on cluster hardware 
architectures. 

* The work presented in this article has been investigated by the authors in the context 
of the HYBRIS (Efficient Specification of Hybrid Systems) project supported by the 
Deutsche Forschungsgemeinschaft DFG as part of the priority programme on Soft- 
ware Specification - Integration of Software Specification Techniques for Applications 
in Engineering. 



H. Ehrig et al. (Eds.): INT 2004, LNCS 3147, pp. 145-173, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 




146 



K. Berkenkotter et al. 



As suggested by its name, HybridUML is based on the syntax of the Unified 
Modeling Language UML 2.0 [OMG03a,OMG03b]. Since core UML does not 
support the specification of time-continuous behavior, a language extension is 
required. To this end, the authors introduce a new profile, that is, a definition 
of new UML constructs introduced by means of UML stereotypes applied to 
existing language elements. In particular, HybridUML extends the UML vari- 
ant of Statecharts by augmenting state descriptions using invariants and flows 
or algebraic conditions. The latter ones describe time-continuous variable evo- 
lutions taking place while the system resides in the respective state. Transi- 
tions may be triggered by conditions and signals (i.e. atomic events) and lead 
to actions consisting of variable assignments and signal generations. Following 
the suggestions of existing formalisms [Hen96,AGLS01], transition execution is 
conceptually performed in zero-time, but with interleaving semantics. Parallel 
components process signals in a synchronous, but non-blocking way: A signal 
s generated by some transition is available in multicast-fashion to other agents 
for their next computation step. Time passes during the phases where agents 
reside in a given state, and time-continuous variables change according to the 
flow/ algebraic conditions applicable in the current agent states. 

The HL 3 framework developed by the authors consists of a re-usable hard 
real-time runtime environment R and a design pattern P for compilation tar- 
gets of arbitrary hybrid specifications. Given a high-level formalism H - such as 
HybridUML - for the description of hybrid systems, transformations <Ph from 
high-level specifications S into instances of the HL 3, pattern P can be 

developed. For (S'), I?), a formal semantics S(<Ph{S), R) is defined so that 
the transformation both provides a semantic definition of S and an executable 
program whose behavior will be consistent with S (L> h (S) , R) . Similar to ma- 
chine code, HL 3 should not be used for manual programming, but as a target 
language for automated transformations. In contrast to machine code, the real- 
time semantics of HL 3 programs can be determined in a direct way, thereby 
assigning formal meaning to the high-level specification used as the transfor- 
mation source. This is achieved by using a very limited range of instructions 
for multi-threading, timing control, and consistent handling of global state in 
presence of concurrency. 

Though today numerous formalisms and verification approaches are avail- 
able for hybrid systems (see references in the related- work section below), their 
application in an industrial “real-world” -context is still rare. According to our 
analysis, two main causes are responsible for this situation: 

— The syntax developed for hybrid formalisms within research communities 
was too specialized and not supported by conventional software engineering 
tools available to practitioners. 

— While the underlying theories supported formal verification by theorem prov- 
ing or model checking, they did not support the development of optimized 
code for embedded control systems. 

With respect to the first cause we suggest to augment existing well-accepted 
formalisms of software engineering by new specification constructs describing 
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time-continuous behavior. From today’s point of view, the Unified Modeling 
Language UML 2.0 is the best candidate for such an approach: It is currently 
the most widely known software-engineering formalism supported by a variety of 
tools. Furthermore, language extension is an inherent feature of UML, therefore 
well-constructed UML tools should support this extension as well. 

The second cause is related to both practical and theoretical considerations: 
From a practitioner’s point of view, the effort invested into formal specification 
and verification - which will certainly be considerably higher than the effort 
spent on elaborating informal conventional specifications - is only justified if the 
specifications can be easily transformed into executable systems. For example, 
we do not expect that the amount of time required for developing executable 
code by step-wise refinement will ever be widely accepted among project leaders 
and developers of embedded systems. 

From a theoretic point of view, the problem is even more subtle: If a trans- 
formation into executable code is available, how can the consistency between 
high-level specification semantics and execution behavior of the low-level im- 
plementation using conventional programming languages and operating systems 
be ensured? A practical consequence of this problem consists in the fact that 
the simulation facilities provided by many case tools never declare which formal 
high-level semantics has been used as a reference for the encoded simulation 
behavior. 

In “classical” UML [RJB99,OMG03a,OMG03b], the definition of a universal 
formal semantics has been deliberately avoided. Instead, the various language 
constructs are only associated with a general informal meaning so that their 
purpose in various modeling situations becomes clear. In [RJB99, pp. 105] this 
approach is motivated by the fact that the semantic interpretation of specifica- 
tion constructs depends on the specific project context, and precise behavior is 
only obtained by transformation into the target programming language. While 
this avoids the obligation to prove consistency between executable system and 
high-level specification semantics, it still poses the problem that in general, it 
will be infeasible to capture the potential behavior of software written in Java, 
C/C-l — |-, or Ada, when executed in a specific target environment. 

Our suggestion to overcome this problem is to restrict the infinite variety 
of possible compilation targets for hybrid specifications according to the HL 3 
framework introduced below: First, the framework fixes a specific hard real-time 
runtime environment which avoids uncertainties introduced by using arbitrary 
operating systems. Second, all specifications written in a given hybrid high-level 
formalism have to be compiled using a transformation function which generates 
instances of abstract classes pre-defined by the framework. As a consequence, 
the variable compilation targets depending on formalism and specification are 
restricted with respect to software architecture and interfaces to the runtime 
environment. Therefore the behavioral semantics of the executable target can 
be given more easily than for an unrestricted compilation into a programming 
language. If the high-level formalisms have been introduced informally, the trans- 
formation defines the semantics as well. If, however, the transformation has only 
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been created in order to translate specifications with given high-level semantics 
into executable code, the consistency between abstract specification behavior 
and executable compilation target still has to be verified. Due to the restrictive 
structure of compilation targets and runtime environment, this proof obliga- 
tion is at least easier to discharge within the HL 3 framework than for arbitrary 
transformations designed in an intuitive way. 

Before presenting a more formal definition, the “look-and-feel” of the new 
HybridUML profile is illustrated in Section 2 by means of a train control sys- 
tems case study defined by the DFG priority programme Software Specification 
- Integration of Software Specification Techniques for Applications in Engineer- 
ing [DFG]. The UML 2.0 profile defining HybridUML in a systematic way is de- 
scribed in Section 3. For illustration purposes, these definitions refer to the case 
study introduced before. Conforming to the general UML approach, the profile 
defines some basic semantic features together with the syntax, but is still quite 
far from a complete formal description of behavioral properties. To achieve this, 
we first introduce the HL 3 framework in Section 4. This is used in Section 5 to 
specify the full HybridUML semantics by providing a transformation into HL 3 . 
Apart from describing the specification capabilities offered by the HybridUML 
profile, this paper focuses on the transformation concept and the semantic model 
of the HL 3 framework. Other areas of interest - such as hard real-time simu- 
lation, automated test data generation against HybridUML specifications, and 
performance measurements of HL 3 implementations on multi-CPU computer 
clusters - are briefly discussed in the conclusion (Section 6), with references to 
current work in progress. 

Due to the usual space limitations, the HybridUML profile definition, the 
HL 3 semantics, and its performance as a time-triggered hard real-time runtime 
environment on cluster architectures cannot be exhaustively described in this 
paper. We refer to [BBHP04] for a detailed description of HybridUML profile 
and [BBH + 04] for semantics, implementation, and real-time measurements of 
HL 3 . 

Hybrid systems have been studied extensively in various research commu- 
nities since the early nineties. The definition and investigation of the Duration 
Calculus (see [ZRH93,RRS03] and further references given there) provided fun- 
damental contributions to understanding Hybrid Systems. The introduction of 
Hybrid Automata [Hen96] demonstrated the feasibility of verification by model 
checking for hybrid specifications. The applicability of hybrid automata to large- 
scale systems was improved by the introduction of hierarchical hybrid spec- 
ifications [AGLS01]. Alternative hierarchical approaches closer to the State- 
charts formalism have been described in [KMP00] (together with a proof theory) 
and [BBB + 99] (verification by model checking). 

We mention GIOTTO [HHK03] as today’s most prominent example of a hard 
real-time language with well-defined semantics. Similar to our HL 3 framework, 
GIOTTO follows the time-triggered systems paradigm described in [Kop97]. 
The time-triggered approach is particularly well-suited for real-time programs 
discretising time-continuous evolutions, since it guarantees bounded timing jitter 
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for periodic schedules. In contrast to this, other approaches to hard real-time 
focus on the fast response to external interrupts, see [RTAI03,Lab04] for popular 
real-time variants of the Linux operating system. 



2 HybridUML by Example: Radio-Based Train Control 

In this section, HybridUML is introduced and illustrated by means of an appli- 
cation example - the specification of a radio-based train control system. This is 
one of two case studies within the scope of the DFG priority programme Software 
Specification [DFG]. 

HybridUML as Profile for UML 2.0. One of the mostly critized points of 
UML 1.4 is the lack of formal specification. Especially the real time community 
needs this for building safe systems. As this fact has not changed with UML 2.0, 
another solution must be found for using UML in the real-time domain. 

To overcome this deficiency, we propose HybridUML as a UML 2.0 profile. 
UML 2.0 offers profiles as a powerful extension mechanism for tailoring UML 
to specific working areas. Based on a metamodel like the Meta Object Facil- 
ity (MOF) or usually UML itself, a profile specifies new model elements called 
stereotypes. Each stereotype is dependent on exactly one element of the corre- 
sponding metamodel (see Fig. 5 for an example). These stereotypes customize 
the used metamodel in different ways: introducing a new terminology, e.g. for 
Enterprise Java Beans, introducing new syntax, either for elements without syn- 
tax or new symbols for elements with syntax, introducing new semantics and 
constraints, or adding further information like transformation rules from model 
to code. A set of stereotypes forms a profile. 

A profile can be applied by a model or a package in a model. All stereo- 
types can be used as modeling elements. As every stereotype extends an already 
known element, the model is still a valid UML model if the profile is taken away. 
Profile application is visualized by a dependency with the key wort <C apply^> 
attached. The profile itself is a package and therefore depicted like this with the 
keyword <^iprofile^> above its name. The HybridUML profile thus takes a subset 
of UML, modifies it according to the requirements on a specification formalism 
for hierarchical hybrid systems, and associates it with a precise semantics. The 
most important constraint on applying the HybridUML profile is using only the 
model elements specified in it. 

Radio-Based Train Control. An important part of the specification of the 
train control system is the coordination of train and railroad crossings in order 
to ensure that whenever the train crosses the road, the crossing is safe (i.e. it is 
locked for cars, pedestrians etc.). A special feature is the absence of signals and 
train monitoring equipment on the track, i.e. train and crossings always guaran- 
tee a safe and consistent state of the complete system on behalf of state requests 
and notifications. Particularly, the train controller continuously (re-)calculates 
velocity-dependent locations on the track at which requests must be sent, or at 
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Fig. 1 . Dynamic velocity profile defined by velocity target points on the track 



which the brake has to be activated. There are related investigations concern- 
ing the “generalized railroad crossing” applying a more abstract model of the 
system, e.g. [HL94]. 

In this case study, a single train is considered that moves on a single track 
without switches. There are velocity target points on the track with dedicated 
velocities that the train must not exceed. There are two kinds of velocity target 
points: (1) Conditional velocity target points are assigned to railroad crossings 
and have a target velocity v = 0. If the crossing is not safe, the velocity target 
point is active and the train has to stop there. (2) The route atlas contains 
a (piecewise constant) static velocity profile that defines a maximum allowed 
velocity for each location on the track. Each location for which this velocity gets 
lower implies a fixed velocity target point, denoting a restrictive velocity change. 
These points are always active. 

Figure 1 is an abstract view on a track example with fixed (vtp[l],vtp[S\) 
and conditional (vtp[ 2]) velocity target points. In consideration of the train’s 
maximum deceleration, the static velocity profile and the velocity target points 
define the dynamic velocity profile, resulting in brake points - the locations on 
the track where the train must start braking in order to reach the target velocity 
at the respective target point. The brake points depend on the train’s current 
velocity; in the diagram, example values for current velocities and V 2 are given, 
whereas v± leads to brake point brakePoint[ 1] and implies brakePoint[ 2] and 
brake Point [3], respectively. A safety-critical aspect of the train control system 
is to ensure that the speed limit of target velocity points is never broken. The 
remainder of this section focuses thereon. 

Architectural Structure. The main building block for modeling architectural 
structure within HybridUML is called agent in conformance with related work. 
Agents are concurrently operating entities and can be combined by parallel com- 
position, or grouped together enclosing them with a hiding operator. For precise 
interface descriptions we distinguish local and global variables and signals. Hy- 
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class TrjinController 




Fig. 2. Structure diagram of agent TrainController. 



bridUML allows communication between concurrent agents via shared variables 
as well as via message passing to model multicasting of signals. 

Agent TrainController consists of several (parallel) agents as defined in its 
structure diagram (Fig. 2), including their interdependencies. It calculates and 
provides the required acceleration a of the train. Therefore the train’s location 
x and the user-requested acceleration a U5er from the locomotive driver are read 
from the environment. These are time-continuously changing variables. Further, 
several locally defined constants affect the computation of a, like the route atlas 
ra which is defined as a data structure. It contains the velocity target points vtp 
that consist of a location x, a target velocity v, and its type (fixed or conditional). 
Finally, radio messages are received that provide status information about the 
railroad crossings. 

The highlighted basic agents BrakePointController and MovementController 
are discussed in the following. 

Agent BrakePointController provides the boolean variable brakingRequired 
that denotes that the train has to brake because of any velocity target point. 
This is determined by the train’s location x, its current speed v, and the set of 
currently active velocity target points (which is defined by vtpActive[] consisting 
of a boolean variable for each velocity target point). 

Behavioral Specification. The behavior of a basic agent is given by an associ- 
ated hieraclrical state machine. As typical for hybrid systems, there are basically 
two ways of acting: either some discrete transition is taken or time passes and the 
continuous variables change over time according to their specified constraints. 
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The behavior definition (shown in Fig. 3) is based on the continuous 
(re-)calculation of the set of brake points brakePoint[i] for all velocity target 
points: 

(1) algeBrakePoint = 

Vi £ {l..VTP_COUNT} • brakePoint[i ] = ra.vtp[i].x — r ° Zmst a ~ 

The variable brakingRequired is set in a discrete fashion, dependent on con- 
dition: 

(2) condBrakingRequired = 

3i £ {I..VTP .COUNT}* 

vtpActive[i\ A brakePoint[i\ < x A ra.vtp[i].v < v A ra.vtp[i\.x > x 

It denotes the situations that require braking because at least one brake point 
of an active velocity target point is reached by the train while its speed is too 
high. Note that only velocity target points in front of the train are considered, 
because particularly the opening of a crossing behind the train shall not affect it. 



statcmachinc movcmcntControl 



statcmac h i n c brakcPointControk 

B ra kin gN ot Req u i retl 
[ inv: “>((2) condBrakingRequired) ] 

[ (2) .torid BrakingRequired ] 

/ brakingRequired true • 



[ — » condBrakingRequired) ] 
/ brakingRequired : — false 



BrakingRequired 



normal 



userCon trolled 



unrestricted 

[ alge: u = a USC r ] 

[inv: (4) con d Unrestricted ] 

[ ((4) condlin restricted) ] 

[ (4) condlJn restricted ] 

•\ / 

restricted 

[ alge: a = 0 ] 

[ inv: — '((4) cond Unrestricted) ] 

[ inv: ((3) condBraking) ] 



[ (3) condBraking ] 

2>l 

enforced Braking 

braking 0“0 | 

[ inv: (3) condBraking] 

[ — >((3) condBraking) ] 
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[ alge: (1) algeBrakePoint ] 



[ inv: t 1 > 0 ] 



-( braking 0"0 ) 



Fig. 3. Behavior of agent Fig. 4. Behavior of agent MovementController. 

BrakePointCont roller. 



Thus the mode BrakingRequired is active for exactly these situations, whereas 
the mode BrakingNotRequired is complementary. The transitions in combination 
with the invariants model the mandatory mode changes according to the condi- 
tion such that variable brakingRequired is always up-to-date. 

The responsibility of agent MovementController (Fig. 4) is to determine the re- 
quired acceleration a. It constrains the user-requested acceleration a user on behalf 
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of brakingRequired, the current velocity v, the currently allowed velocity v a || owec j, 
and a special signal emergency. It is modeled strictly hierarchically, initially in 
mode normal. Submode userControlled maps the user-requested acceleration to 
a, whereas submode enforcedBraking forces the train to brake. Similarly to Brak- 
ingRequired, the active submode directly depends on a condition: 

(3) condBraking = 

brakingRequired V v > v a iiowed 

In case of enforced braking, the submode braking defines a to be the maximum 
deceleration until the train stops. Otherwise, there is a distinction between unre- 
stricted and restricted appliance of a user : The mode restricted guarantees that the 
minimum (0) and maximum (v a || owet j) velocities are not violated, else unrestricted 
maintains a = a user . Again, a condition controls this: 

(4) condUnrestricted = 

(u <C V allowed V &user — 0) A (u > 0 V a user ^ 0) 

Finally, mode braking is re-used in movementControl - if the signal emergency 
(that is caused by violating a velocity target point) is received, the train is 
definitely stopped. 

3 The HybridUML Profile 

In this section we give a brief overview on the most relevant elements of the 
HybridUML profile, their relation to existing UML constructs, and their intuitive 
semantics. For a detailed language description we refer the reader to [BBHP04]. 

Types and Expressions. HybridUML uses typed variables. As UML provides 
only Integer, String, and Boolean as basic types, we have to extend explicitly 
PrimitiveType to get the datatype Real. In this way, we can use real-valued 
variables within the profile. For better separaton of concerns, we also need ana- 
log real numbers as extension which can be changed continuously according to 
flow conditions in Modes while variables of type Real can only be changed dis- 
cretely by transitions. AnalogReal thus is a specialization of Real. For better 
readability in large applications, we introduce StructuredDataType as an in- 
stance of DataType to define a structure. All StructuredDataTypes of a model 
are implicitly collected in a package which is imported by all diagrams of this 
model. 

For describing the valuation of AnalogReal variables, specific expressions 
are needed, i.e. differential expressions and algebraic expressions. Invariant ex- 
pressions are needed to define state invariants. RTExpression is an instance of 
Expression (see Fig. 5) which defines mathematical and logical terms that may 
be dependent on time. RTExpression is an abstract metaclass that cannot be 
instantiated. 

The real-time expression is given as a string, just as in Expression. Furthermore, 
the expression must be mathematically or logically evaluable. The notation and 
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DifferentialExpression 
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AlgebraicExpression 




«stereotype» 

InvariantExpression 



Fig. 5. Stereotypes for RTExpressions 



semantics are given by the concrete subtypes, i.e., specializations of RTExpres- 
sion, which are: AlgebraicExpression, to describe algebraic terms dependent on 
time, DifferentialExpression, to describe differential terms dependent on time, 
and InvariantExpression, to describe logical terms used for modeling invariants 
a variable must fulfill. 

Constraints. To describe the restrictions on the valuation of analog variables 
in modes we introduce RTConstraints. As an instance of Constraint, RTCon- 
straint is a UML constraint which is restricted in order to describe an RTEx- 
pression. DifferentialExpressions and AlgebraicExpressions can be attached to 
AnalogReal variables, InvariantExpressions can be attached to all variable types. 
RTConstraint is visualized in the same way as UML 2.0 constraints, i.e. an RT- 
Expression term given in curly brackets. In Modes, brackets are used. 

Clocks and Timers. We do not use the UML 2.0 time model as it has no formal 
semantics and as it is not powerful enough for our purposes. A Clock is modeled 
by a variable of type AnalogReal that uses a DifferentialEquation for modeling 
the flow of time. Therefore we inherit from AnalogReal to get a clock. The flow of 
time is specified as a differential equation: Let t be the value of a Clock instance. 
Then the following expression always holds: t = 1. As the differential equation is 
explicitly given, it is not added as a constraint following the variable. Similarly 
we have timers which are set with a value and count downwards, consequently 
they are specified by the differential equation t = — 1. 

Variables and Signals. Variables in HybridUML can be shared between agents 
for communication purposes. They are visualized in the same way as UML 2.0 
Ports, which are linked by connectors. The shared variable model requires con- 
nected interfaces to hold the same value. VariablePorts are depicted as a rectan- 
gle on the boundary of the owning classifier. Instead of visualizing the attached 
interfaces in lollipop-notation, a required interface (corresponding to read-only 
access) is a white filled rectangle and a provided (corresponding to read/ write 
access) interface is a black filled rectangle. In class diagrams, only the variable 
owned by the Variablelnterface of the port will be shown. 

RTSignals are introduced as a different means for communication between 
Agents, as pure communication via shared variables can be managed when mod- 
eling small systems, but tends to be cumbersome for larger systems. RTSignal is 
an instance of Signal (from Common Behaviors) which defines an asynchronous 
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message. An RTSignal is depicted in composite structure diagrams in correspon- 
dence with SignalPorts and Signallnterfaces similar to shared variables. 

Using these elements of UML allows to represent the communication struc- 
ture between agents in a composite structure diagram (see Fig. 2) as far as their 
shared variables and signals are concerned. In statemachine diagrams, RTSignals 
are used in combination with SignalEvents and ModeTransitions. SignalEvents 
carry RTSignals. They are used as triggers in Modes. Nevertheless, we prefer the 
term event as this is usual for state machine models. 

Agents. Agents are stereotypes of classes and consist of VariablePorts, Signal- 
Ports, private variables, Modes, initial states, and parameters. Initial states are 
specified in Agent instances just as concrete values for parameters. Modes are 
class variables and cannot be changed by Agent instances. Parameters are used 
for better scalability. They specify constants that can be used in invariants and 
other expressions used in the Agent instance and its Mode(s). 

An Agent instance can own an internal structure which may consist of Agent 
instances itself. Agents communicate by shared variables (represented by Vari- 
ablePorts and VariableConnectors) and signals (as modelled by SignalPorts and 
SignalConnectors) . 

In the HybridUML profile we distinguish basic Agents which are not nested and 
own a single top-level Mode, and composite Agents which are composed from 
subagents and have many top-level Modes. Clocks are global for all parts of an 
Agent. We do not model them as VariablePorts as this would be obfuscating. 
Parameters are constant global variables for usage in constraints of all kind. 
The top-level Modes define the behavior of the system. The semantics of a basic 
Agent are defined by the (trace) behavior of its top-level Modes, constructed 
from the respective relations describing the continuous behavior and the discrete 
transitions of a Mode (see below). 

The standard operations on concurrent components like the composition of 
two Agents Ai||A. 2 , application of a hiding operator, and renaming of the vari- 
ables of an Agentlnstance, can be reflected in the representation of an Agent’s 
internal structure in a composite strucure diagram. An execution of an Agent A 
follows a trajectory, which starts in some initial state and is a sequence of flows, 
i.e. continuous changes to the analog variables, interleaved with discrete steps 
of agents. While continuous steps are performed simultaneously by all Agents, 
discrete steps are performed by one Agent at a time, possibly changing variables 
or taking part in communication via events. 

Agents are depicted like UML classes with internal structure. In a class dia- 
gram, the internal structure is visualized as aggregated classes. The parameter 
list of each Agent is given behind its name in parentheses in the first compart- 
ment of the class symbol. VariablePorts and their included Variablelnterfaces 
and variables as well as SignalPorts and their included Signallnterfaces and sig- 
nals are given as attributes in the second compartment of the class symbol. In 
the class diagram, for variables only the name and type are shown, for signals 
the name and parameters are given. Optionally, in the third compartment of the 
class the Mode of the Agent is given. This is the name of the Mode followed 




156 



K. Berkenkotter et al. 



by concrete parameters listed inside parentheses. A parameter of a Mode may 
also be a parameter of the Agent, i.e. the concrete value is given in an Agent 
instance. 

The internal structure of composite Agents is shown in a composite structure 
diagram (see as example Fig. 2). The name of the Agent is given in the upper left 
corner with the keyword class before it. After that, the concrete parameters of 
the composite Agent follow. Here read/write access of global variables is shown 
as ports with required and provided interfaces. The same holds for sending and 
receiving signals. 

Agent instances are visualized as objects in composite structure diagrams. 
Behind the objects’ name and type the concrete parameters are given in paren- 
theses in the first compartment of the object symbol. In the second compartment, 
optionally the respective initState is given as a constraint, i.e. in curly brackets. 
The Mode of the Agent is given in a stateclrart diagram. The name of the Mode 
with the keywort statemachine before it is given in the upper left corner of the 
diagram. 

Modes. Sets of states of a basic agent are described by Modes which may con- 
tain submodes themselves and transitions. In our profile, Mode is an instance of 
StateMachine describing an Agent’s behavior. As Modes may have flow condi- 
tions, they are (hierarchical) hybrid state machines. Each Mode contains exactly 
one region, i.e. there is no parallel behavior inside a Mode. It is entered and left 
by control points, which are partitioned into entry and exit points. Top-level 
Modes are connected to an Agent. They use the global variables and signals 
defined in this Agent. Modes can have parameters for better scalability. Within 
Modes, the time-continuous behavior is defined by differential equations and 
algebraic constraints and limited by invariants. When a mode is executing a 
continuous step, the hierarchical state machine as a whole is acting, i.e. modes 
on all levels, from the top-level mode to the leaf modes, have to coordinate for 
this. Part of this coordination is that any possible valuation of analog variables 
has to comply to the constraints attached to all active modes on the various 
levels. 

Discrete steps are described by transitions between modes where taking a 
transition does not take time. Transitions consist of a condition part and an 
action part. As condition, we can have a boolean expression, i.e. firing that 
transition depends on the state, or a signal trigger, i.e., an event based invocation, 
or both. As action of a transition we allow instantaneous operations on variables 
and sending of a signal. When a transition is taken, discrete variables may be 
updated or signals can be sent and received. Preemption and interrupts are 
modeled by using group transitions, i.e. exiting a higher level Mode via some 
distinguished exit point. 

An execution of a Mode consists of a sequence of steps which can be cho- 
sen out of three different types: a continuous step according to the respective 
constraints, a discrete step according to the condition and action of a transition 
within the mode, and an environment step that can change all but the local vari- 
ables of that mode. The last variant represents an activity of a different Mode 
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on the same hierarchical level. For a top-level mode no environment steps in this 
sense are possible, as it is the solitary Mode of that level. 

Modes are visualized the same way as UML 2.0 StateMachines (see Fig. 4). 
Parameters are given behind the name of the Mode in parentheses. The invariant 
is marked inv, the flow conditions with flow , and algebraic expressions are marked 
with alge. As these are constraints, they are given in brackets. 

Transitions. In order to provide a clear-cut interface of Modes while avoiding 
inter-level transitions we use control points for Modes as sources and targets of 
transitons. Entry points are depicted as small circles on the border of a Mode 
with an optional name attached to it while exit points are depicted as small 
solid black-filled circles. Every Mode has one default entry point and one default 
exit point which are not depicted explicitly. We employ ModePseudostate as an 
instance of Pseudostate to denote control points. 

ModeTransition is an instance of Transition depicted by an arrow with open 
arrowhead. ModeTransitions are taken according to their condition part, i.e. , 
their guard constraints or a triggering SignalEvent. The guard constraint is given 
in brackets followed possibly by the SignalEvent. The ModeTransitionActivity 
is separated from the guard by a slash. In UML 2.0, Transitions can only have 
Activities as effect. As ModeTransitionActivity thus is an instance of Activity, it 
can be an updateActivity which updates variables according to some instruction, 
or it can be a sendActivity which emits a SignalEvent. 



4 HL 3 — The Hybrid Low-Level Language Framework 

As indicated in Section 1, the Hybrid Low-Level Language Framework HL 3 is a 
generic compilation target for hybrid high-level formalisms H . It has been de- 
signed to support the transformation <L>h of specifications S written in H into 
executable code (<Lh(S), R), thereby assigning a formal semantics S(<Ph{S), R) 
to the compilation target. The generated HL 3 program is suitable for hard real- 
time execution, to be used either for developing embedded applications or for 
their automated test in lrardware-in-the-loop configurations. The concepts de- 
scribed here have been implemented on multi-CPU computers where CPUs can 
be reserved exclusively for the HL 3 runtime environment. In order to support 
executability on specific target hardware, high-level specifications S consist of 
three parts: (1) The behavioral specification Si, written, for example, in Hy- 
bridUML, (2) the architectural specification S 2 describing the available cluster 
nodes, CPUs, hardware interfaces and the mapping from Si -objects to concrete 
hardware, (3) the physical constraints specification S3 describing the required fre- 
quencies for the discretization of time-continuous evolutions, writing to/reading 
from hardware interfaces, as well as the required precision for discrete time- 
dependent steps. 

The framework is sketched in Fig. 6, with additional definitions of basic types 
shown in Fig. 7. Its underlying idea is to provide a re-usable hard real-time 
processing infrastructure - the runtime environment R - and a design pattern 
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Fig. 6. Design pattern for the HL 3 run-time environment. 



P for the formalism- and specification-dependent components to be executed 
within the runtime environment. 

The HL 3 runtime environment R consists of a user space Scheduler running 
on reserved CPUs without interruptions from the underlying operating system 
(Linux with a kernel-extension developed by the authors’ research group). In 
addition. TimeService and a communication service (Channel and ClusterCom- 
munication) provide the mechanisms to ensure consistent data views within the 
cluster configuration. The Scheduler enforces time-triggered, real-time system be- 
havior [Kop97]: All activities to be performed by the components of a HL 3 
instance are scheduled at pre-determined points in time which are multiples of 
a fixed time unit. 

The design pattern P consists of the abstract classes AbstractMachine, Se- 
lector, Transition, Flow, Interface Module, and their relations with each other 
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and with the runtime environment R. Pattern P facilitates the development 
of the transformation <1>h by defining the abstract interfaces and relationships 
we regard as essential for creating the full compilation target. Instances of Ab- 
stractMachine are used to implement the local behavior of sequential components 
specified in the high-level formalism. Each new high-level specification S gives 
rise to a new set cxh{S) of abstract machines, to be generated by a transforma- 
tion an- The Selector enforces global behavioral constraints on the concurrent 
systems, such as the synchronous execution of transitions. Since these constraints 
depend on the formalism H , but not on the concrete specifications S, Selector 
has to be instantiated just once for each new high-level formalism H . As we are 
dealing with hybrid systems, sequential components may run through discrete 
and time-continuous processing phases. Discrete steps are represented in HL 3 
by instances of Transition, time-continuous ones by instances of Flow. 

For handling application-specific hardware interfaces, another abstract spec- 
ification is given: Instances of Interface Module create a hardware abstraction 
layer, hiding driver-specific details and the location of hardware interfaces within 
the cluster from scheduler, flows, and transitions. 




VisibilitySet 

+visibleAt: set of VisibilityAttribute 




Fig. 7. Basic types referenced in the HL 3 framework. 
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As a result, the complete transformation <Ph from H into executable HL 3 
instances can always be structured as 

&h(S) = (aH{S) 1 T H (S),<j)H{S), lh{S), Selector#) 

where a#, th, 4>h, and lh generate collections of abstract machines, transitions, 
flows, and interface modules, respectively. 

In the paragraphs below, additional details of HL 3 are presented. For a 
complete description, the reader is referred to [BBH + 04], 

TimeService. Executable HI? systems are clusters connected by high-speed 
local area networks. As a consequence, relativistic effects between cluster nodes 
may be neglected, so we can assume the existence of global physical time, denoted 
by @t £ R + with physical unit [sec]. The HL 3 TimeService provides a cluster time 
value clustertime £ N (corresponding to the notion of global time in [Kop97]) 
which is related to physical time according to 

@t = 7 • clustertime + lo + it, where 7r £ [—7 — H, 7 + 77] 

Constant 7 £ Q is the cluster time granularity with physical unit [sec] , u is 
a constant to be added because clustertime begins at 0 on cluster startup, and 
n is the precision of the cluster time, taking into account physical clock drift 
and jitter between clocks at local cluster nodes. Typically, 10 -9 < 7 < 10 -6 and 
precision values 77 < 10/zsec are feasible, using combinations of software and 
hardware clock synchronization mechanisms. 

Logical HL 3 - time can be obtained by all HL 3 programs as a pair t 0 .t\ £ 
timeTick with type timeTick = N x N, and the natural ordering ao.ai < bo-bi 
iff ao < bo V ao = b 0 A ai < b\. Component to represents the time tick as visible 
to the time-dependent conditions evaluated in abstract machines. It is always 
ensured that to < clustertime, but - depending on the high-level formalism to 
be encoded in HL 3 - to may be kept constant for several ticks of clustertime, in 
order to simulate the execution of transitions in zero time. The second component 
ti of the logical HL 3 - time is used to distinguish causally related events which 
occur during the same time tick to- Component t\ is reset when to is incremented 
and increased between different transition scheduling phases. 

Within the HL 3 framework, the Selector component is responsible for main- 
taining the desired relation between logical HL 3 - time and clustertime via the 
setHL3time() operation provided by TimeService. 

Channels. One of the main objectives of the HL 3 infrastructure is to 
provide a consistent view on global model data. This is motivated mainly 
by three requirements: (1) To our knowledge, all existing high-level for- 
malisms are based on an atomic transition concept: For processing transition 
[C{x 1 , . . . , x n )\e/ a(x\, . . . , x n ), it is assumed that the valuations of all variables 
(xi , . . . , x n ) referenced in condition or action expressions do not change while the 
expressions are processed. Even in formalisms which do not postulate zero-time 
for transition execution it is always assumed that the calculation is performed 
atomically - meaning in zero-time ■ but time passes before the earliest possible 
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point in time when the next transition can be fired. (2) The discretization of 
time-continuous flows requires that all flows synchronously performing a At in- 
tegration step view the same pre-state of all observables, even if only one CPU 
is available for processing quasi parallel integration steps. In particular, state 
changes performed by one flow must not become visible to other flows referenc- 
ing the related variables before the actual integration step has been completed. 
(3) As the HL 3 framework supports cluster hardware architectures, a consistent 
view of data at all cluster nodes is mandatory. 

To implement these requirements, HL 3 uses abstract data types called Chan- 
nels. Channels are data containers providing two operations (see Fig. 6): The 
put(d:seq of byte,v:VisibilitySet) method stores data items d in the 
channel c, together with a VisibilitySet v. The elements of v are VisibilityAt- 
tributes a = (t, scope), where t = to-ti is a logical HL 3 time tick and scope a set 
of abstract machine or interface module identifications. The interpretation of a 
is as follows: When retrieving the data from a channel using the d = c . get (id) 
command, the returned value d satisfies the following constraints: 

3x £ c.e, a £ x.v.visibleAt, • (a '.data = dA id £ a. scope A a.t < getHL3TimeO) A 

(Vy £ c.e, b £ y .v .visible At • {id £ b. scope A b.t < getHL3Time() => b.t < a.t)) 

Intuitively speaking, the identification id of the caller is a member of a scope 
attribute set associated with d. Among all data items contained in the channel 
such that id is within their scope, d is the most recent entry associated with a 
visibility time attribute which is less or equal to the current logical HL 3 time 
value. 

By associating a set of visibility attributes with each data item contained 
in a channel, it is possible to widen the visibility scope at later points in time. 
This can be used, for example, in formalisms where changes become immediately 
visible within the local context of the executing agent, but are published later 
to other agents (e.g. at the beginning of a new macro step). 

Every put ( ) operation on a channel leads to immediate distribution of the 
data within the whole cluster. This is performed by the ClusterCommunication 
service. If the visibility attributes refer to a future point in time, all cluster nodes 
will have a consistent view on this data, as long as the distribution is completed 
before the data becomes visible. 

Abstract Machines. Sequential components of a high-level formalism are 
mapped to Abstract Machines in HL 3 . The task of each abstract machine is 

— to indicate which transitions might be taken by the sequential component, 

— to enable and disable flows according to the current state, and 

— to indicate whether a flow phase may be started according to the abstract 
machines’ local state. 

While the concrete behavior of an abstract machine depends on the high-level 
formalism and the concrete high-level specification, the HL 3 framework defines 
a universal abstract interface for them: Operation getTrans(id:amId) returns 
the list of all transitions which might be performed in the current state. To this 
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end, the abstract machine evaluates both the local static location data and the 
global state provided by channels. Since abstract machines represent sequential 
components, all high-level formalisms with a notion of nondeterminism require 
to select one out of several transitions which might be chosen in a specific state. 
Observe, however, that abstract machines do not perform this selection and 
never trigger associated actions. The former task is delegated to the Selector, 
the latter to the Scheduler. 

After some enabled transition has been selected and its action per- 
formed, the associated abstract machine is notified by the scheduler (opera- 
tion notifyTransO) to trigger changes between locations within that abstract 
machine. The execution of actions associated with transitions will generally af- 
fect the global state encoded in channels. Therefore, the scheduler will call the 
update () operation of each abstract machine after transitions or flows have been 
performed. This operation initiates a new evaluation of all invariants and tran- 
sition conditions applicable in the present state, possibly leading to a new set of 
enabled transitions within each abstract machine. 

We expect that in every conceivable high-level formalism the execution of 
flows or transitions is mutually exclusive. Otherwise racing conditions might 
prevent the discrete change of observables due to simultaneous changes by flows. 
As a consequence, an abstract machine may indicate whether in the current state 
only transitions, only flows, or one of both may be performed. Depending on the 
local abstract machine state, the execution of flows may be disabled. This may 
happen in the case of high-level formalisms based on the maximal progress con- 
cept (sequential components with enabled transitions must fire) or allowing the 
definition of urgent transitions. Flows are also disabled if the abstract machine 
resides in a location whose invariant has just been violated, so that a transi- 
tion becomes mandatory. The information whether flows may be performed is 
obtained via the isFlowEnabled(id:amId) operation. 

A technical detail related to distributed execution of HL 3 components is indi- 
cated by the fact that the getTrans(id:amId) and isFlowEnabled(id: amid) 
operations have been declared on class level in Figure 6: While each abstract 
machine instance is created on a single cluster node only, where also their 
init(), update (), and notifyTransO operations are scheduled, getTransO 
and isFlowEnabledO may be called anywhere. This is motivated by the fact 
that the Selector should be able to call these operations from arbitrary nodes. 
The suggested implementation for abstract machines is to store the actual return 
values of these operations in associated channels, at the end of each update () 
operation. Since channel data is consistently available on all nodes, getTransO 
and isFlowEnabledO can return these values wherever they are called. 

Selector. The Selector is a centralized instance enforcing synchronization con- 
ditions for transition execution with respect to the high-level formalism. The 
abstract interface required by the HL 3 framework offers a getSelectionO op- 
eration to the scheduler. It returns an indication whether a flow phase may be 
started and a (possibly empty) set of transition identifications with associated 
visibility sets. The transitions returned are the result of a selection procedure 
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among all possible transitions offered by the abstract machines in their current 
state. In formalisms where transition sequences are supposed to be executed in 
zero time, the Selector keeps the same value for logical HL 3 time to until all 
transitions within a zero-time step have been performed. Before the next flow 
phase, logical time is adapted to physical time. The actions associated with 
these transitions can be concurrently scheduled. Since actions derive pre-state 
from channels and change global state via channels as well, they may be triggered 
on arbitrary nodes and CPUs. 

Note that even for the same high-level formalism it can be useful to apply 
different Selector instances: For application development, a selector will usually 
resolve nondeterministic transition selection - which may be allowed according 
to the high-level formalism - to deterministic execution sequences. In contrast 
to this, a simulation or testing system will require a selector which is capable of 
producing all transition schedules possible according to the high-level formalism. 

Transitions. Instances of Transition implement atomic state transformers, en- 
abled by abstract machines. In order to support the partitioning of high- 
level model state into discrete locations and additional variables, transi- 
tions are equipped with a trigger condition, represented by Boolean function 
condition!) . In contrast to high-level formalisms allowing condition expressions 
over global or local variables, HL 3 requires that condition functions retrieve state 
information from channels. The associated get (id) calls use the identification 
of the abstract machine owning the transition. Furthermore, each transition is 
associated with a (possibly empty) Action, implemented as a function reading 
the same channel data pre-state as the trigger condition, but also setting a post 
state via channels, to become visible at the point in time and for the indicated 
scope defined by the input parameter. Observe that HL 3 transitions are not 
equipped with any signal or event mechanism. We consider these as objects of 
higher-level formalisms, to be implemented in HL 3 by means of channels, the 
scheduler, and the selector component. This design decision could be revised 
as soon as the hardware platforms could provide semantically well-defined and 
fast signal mechanisms. However, our analysis of current PC or embedded con- 
troller hardware indicates that there is no such universally suitable mechanism 
for the embedded application domain. The concept of locations - if required by 
the high-level formalism - is encoded inside abstract machines. As a result of an 
action execution, abstract machines may be suspended, activated, or stopped, 
and the guards enabling/disabling flow execution may be set. 

Flows. Instances of Flow represent integration functions as a result of the dis- 
cretization of time-continuous evolutions. The scheduler will activate all flows 
according to their specified frequency, provided that their guard attribute evalu- 
ates to true. The integration function integrate (v: VisibilitySet) is written 
in standard C/C++ syntax, but retrieves pre-state from channels instead of 
global or static local variables. Since flows are executed on behalf of their en- 
abling/disabling abstract machines, they inherit the scope from the abstract 
machine. Based on current logical HL 3 time, the integrate ()-operation reads 
the latest visible state and writes global data back to channels, to be published 
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according to the visibility set v. Observe that HL 3 flows require integration 
functions which can be called with regular frequency. If the high-level formalism 
specifies flows by differential equations, these have to be solved using separate 
tools - such as Matlab - generating numerical libraries from given differential 
equations, for the purpose of discrete At integration. 

Interface Modules. A hardware abstraction layer conforming to the time- 
triggered system concept is provided by Interface Modules which are software 
components in one-to-one correspondence with hardware interfaces. Interface 
modules are scheduled with fixed frequency and perform an abstraction from 
raw data received on hardware interfaces to channel data and vice versa. When 
scheduled with the poll(v: VisibilitySet) operation, raw data is read from 
the interface and placed into the abstraction channel, using the visibility set 
passed by the scheduler with the call. If to-ti is the HL 3 time tick when the 
data has been received, the visibility set v ensures that the data will have been 
distributed to all cluster nodes before the earliest publishing time t' 0 .t\ > t 0 .ti 
defined by any visibility attribute contained in v. Conversely, each interface 
module retrieves the latest visible version of the associated channel data when 
scheduled and transmits this data item via driver and interface hardware. Ob- 
serve that interface modules allow to use also interrupt-driven hardware devices 
in a time-triggered system: Interrupt handlers store the received data in inter- 
mediate buffers. Interface modules read the buffers when they are scheduled and 
publish the data via channels for the next periodic point in time, as required for 
the given interface in the physical constraints specification. 

Scheduler. Based on the synchronized cluster time introduced above, the Sched- 
uler dispatches activities according to the following concept: Periodic scheduling 
of flows and interface polling is pre-planned at compile time, following the prin- 
ciples introduced for GIOTTO [HHK03]. For optimization purposes, activities a 
whose changes become effective at logical HL 3 time (uq.ui) may be scheduled 
simultaneously with activities b to be published at (vo-iq) < (wo-Ui), if the pre- 
states for a are based on the visibility at an earlier time tick (wq.Wi) < (vo-Vi). 
Since all activities as well as the cluster communication have bounded maxi- 
mum length, each scheduler instance can determine when to start a new activity 
whose pre-state depends on the result of preceding ones, without the need to 
implement a commit protocol between cluster nodes. 



5 HybridUML Semantics 

The semantics of HybridUML specifications is defined by a transformation 
@huml to the Hybrid Low Level Language HL 3 . As required by the HL 3 
framework, a HybridUML specification is mapped to a selector and a collection 
of flows, transitions, and abstract machines (the aspects depending on architec- 
tural and physical constraints specifications are not considered here). 

As described in Section 3, the main building block of a HybridUML speci- 
fication is a set of basic agent instances. Their infrastructure for interaction is 
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provided by connections between sets of variables or signals from different agent 
instances such that connected variables actually denote the same single shared 
variable or signal, respectively. For each connected set of variables or signals 
that cannot be extended we choose a unique Channel in terms of the low-level 
language HL 3 as representative of this set. This includes singleton sets, i.e. un- 
connected global variables and signals as well as local variables. As each variable 
and each signal is mapped to exactly one maximal set of connected variables or 
signals there is a function chan :Var U Sig —> Charihiz that identifies the cor- 
responding channel of a variable or signal. Signals are represented as channels 
carrying boolean data. 



Transformation 4>huml of Algebraic and Flow Constraints. Algebraic 
and flow constraints of the HybridUML model are distributed over the modes 
of the basic agents. They define the set of HL 3 - Flow instances by a mapping 
flowhi 3 : Flow U Alge —> FloWhi 3 ■ (1) The operation integrate() is provided by 
a mapping proc : Exp — > ophi 3 that defines an HL 3 operation of the form void 
op() for each HybridUML expression. The mapping of algebraic expressions is 
straightforward - variables v are mapped to local HL 3 variables that are read 
from or written to chan(v), operators are mapped to corresponding HL 3 oper- 
ators. Flow expressions are transformed by use of an appropriate (numerical) 
mathematical toolkit like Matlab. (2) For the boolean guard, a separate Chan- 
nel is created. It is controlled by the abstract machine (described below) that 
corresponds to the flow constraint of the HybridUML model. (3) The frequency 
is obtained from the physical constraints specification. (4) A consecutive id is 
generated. 

Transformation tjjuml of Transitions. Transitions in the HybridUML 
model connect the submodes of basic agents. The Transition instances t as well 
as the corresponding instances a of Action and c of Condition are given by 
transhi 3 '■ Trans —> {(f, a, c ) £ TranShi3 x Acthi 3 x Condhi 3 | t.a = a A t.c = c}. 

Transitions. A Transition instance is created that contains one condition and 
one action as described below. A consecutive transition id is generated. 

Conditions. (1) The operation isTrueCondition() evaluates a boolean expression 
that is given by a mapping bexp : Expb 00 i ophi 3 - Similarly to proc, the map- 
ping provides C expressions that directly implement the expression from the 
HybridUML model; quantifiers on finite sets are realized by f or-statements. 
Additionally, the (optional) signal is incorporated and treated as a conventional 
boolean variable. (2) The read set is created from the channels of the variables 
and the signal within the generated expression. (3) A consecutive condition id is 
generated. 

Actions. (1) Similar to the integration operation of flows, action(. . . ) is defined 
by proc; sending of signals is realized by sending true on the corresponding 
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channel. The visibility parameter of action(. . . ) is applied to the channels of the 
write set exactly as it is received (see below). (2) The writeSet consists of the 
channel identifiers that correspond to the written variables, i.e. the variables from 
action (. . . ) that are on the left-hand side of assignments. (3) The variables from 
the right-hand sides define the channel identifiers in readSet. (4) A consecutive 
action id is generated. 



Transformation olhuml of Sequential Control Components. Sequential 
control components are exactly the basic agent instances mentioned above. They 
are represented by instances of AbstractMachine: am : Agentbasic —> AMhi3 ■ Note 
that the arrangement of the basic agent instances to composite agent instances 
(through some levels of hierarchy) only provides the distribution and renaming 
of shared variables and signals, which is completely represented by the channel 
mapping chan. 

An abstract machine defines the discrete behavior of a top-level mode, which 
in turn defines the discrete behavior of exactly one basic agent. 

Data structure. The abstract machine defines a (recursive) data structure that 
maps to the hierarchical structure of the top-level mode, such that the Mode 
instances form a mode tree. Within the tree, the sequence of active submodes, 
beginning with the root mode, constitutes the mode configuration, i.e. the set of 
all currently active modes. Based on the mode tree, the data structure is defined 
in a straightforward way: 

Mode: A Mode consists of a set of control points of type ControlPoint, a set 
of submodes of type Mode, a set of transitions of type ModeTransition, a set of 
flow constraints of type FlowConstraint, and a set of invariant constraints of type 
InvariantConstraint. Additionally, a history variable points to the currently ac- 
tive submode. InvariantConstraint: An InvariantConstraint contains a boolean 
function that evaluates according to a mode’s invariant specification. Flow- 
Constraint: A FlowConstraint represents an algebraic or flow constraint from 
the HybridUML model. It references the low-level Flow according to flowhiz- 
Particularly, the boolean guard is controlled in order to enable or disable the 
associated integration operation, depending on the current mode configuration. 
ControlPoint: A ControlPoint contains outgoing transitions of type ModeTran- 
sition. Furthermore, a reference to its parent mode is included. The distinction 
between entry and exit control point is included as a flag. ModeTransition: 
A ModeTransition connects a source and a target ControlPoint. It can fire, if 
its Signal is present, and if its Guard evaluates to true. The firing of a tran- 
sition (possibly) causes a discrete state change, therefore it is associated with 
the corresponding low-level transition of type Transition assigned by transhi 3 
that encapsulates this. Since a transition may affect the history of its containing 
mode, a reference to the Mode is also contained. Signal: A Signal references a 
boolean flag that denotes if the corresponding signal is currently active. Guard: 
A Guard contains a boolean function that implements the corresponding guard 
of a transition. 




Executable HybridUML and Its Application to Train Control Systems 167 



Additional entities exist in the data structure but are not described here. 
They are used for efficiency; for example, the set of currently enabled transitions 
is stored explicitly. 

Data structure instantiation. A basic HybridUML agent defines an instance of 
the data structure: For each mode, an instance of Mode exists. Each Mode apart 
from the top-level mode is inserted into its parent’s set of submodes. For its 
algebraic and flow conditions, FlowConstraint instances are created and linked to 
the appropriate Flow instances. Every invariant expression is represented by a 
boolean function bool expO provided by bexp. A ControlPoint instance is cre- 
ated for every control point of the specification and linked with the corresponding 
Mode. 

Each transition from the HybridUML model is represented by a ModeTran- 
sition instance which is linked to the ControlPoint instances that represent its 
source and target, respectively, as well as with its parent mode. The transition’s 
parent mode is the mode for that it connects either two submodes or the mode it- 
self with a submode. Every ModeTransition is equipped with a Guard, an optional 
Signal, and the Transition instance described earlier. The guard, the signal, and 
the action are taken from the HybridUML model in the same way as described 
for low-level Action and Condition instances, whereas the guard represents the 
Condition without signal. Figure 8 shows the data structure instance for the basic 
agent BrakePointController from Section 2. 

(5) readSetTransBrakingRequired = 

{v | 3i G {1. .VTP .COUNT}* 
v = chan(vtpActive[i]) V v = chan(brakePoint[i])\/ 
v = chan(ra.vtp[i\.v) V v = chan(ra.vtp[i\.x ) 

} U { chan{x ), chan(v)} 

The HL 3 operations within guards and invariants (as well as actions and flows) 
operate on the HL 3 channels (representing the HybridUML variables and sig- 
nals). Therefore, local HL 3 variables of appropriate types are used and dis- 
tributed to the respective channels. 

Execution semantics. The semantics of the abstract machine is given by the 
execution of the set of provided operations: 

init(): Executes the initialization step of the agent: The top-level mode’s de- 
fault entry point is entered. notifyTrans(tr:transID): Accepts the notification 
which transition was chosen and executed externally. Internally, the correspond- 
ing ModeTransition fires without executing its action, thus here it adjusts its in- 
ternal state correspondingly by entering a new control point. updateQ: Updates 
the internal data structure with respect to the current values of the correspond- 
ing channels: (1) A flag flowEnabled is set if this abstract machine is in a state 
that allows time to pass. This is given iff all invariants of the mode configuration 
are satisfied and there is no mandatory step. Therefore, the invariants of the 
mode configuration are recalculated. A mandatory step is a step that initially 
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action () — procf brakingRcqn ired false) 



Fig. 8. Instantiated data structure of Agent BrakePointController. The mode tree is 
highlighted. 



consumes a signal (i.e. that is triggered by a signal) or a step that does not start 
at a default exit point. (2) The set enabled Trans of enabled transitions is gener- 
ated. (3) The set enabledTrans and the flag flowEnabled are written to respective 
special channels, such that exactly these values are provided by subsequent calls 
of getTrans(amld) and isFlowEnabled(amld). 

The precise behavioral description of the above operations is given by their 
implementation. For example, notifyTrans (id : ID) defines a discrete step: 1 
Abstract Machine. The transition itself fires: 

void AbstractMachine :: notifyTrans (transID tr) { m_trans [tr] . f ire () ; } 
ModeTransition. The transition fires by (1) leaving its source control point, 
(2) (optionally) resetting a consumed signal, (3) modifying its parent mode’s 

1 The remaining definitions are omitted because of space restrictions. 








Executable HybridUML and Its Application to Train Control Systems 169 



history and (4) entering its target control point. 

void ModeTransition: :fire() { 

m_source . leave O ; if (m_pSignal != 0) m_pSignal->setActive (false) ; 
writeHistory () ; m_target . enter () ; } 

ControlPoint. When a control point is left, its parent mode has no active 
control point anymore: 

void ControlPoint: :leave() -(getParentModeO . setCurrentControlPoint (0) ; } 
When a control point is entered, it becomes the active control point of its parent 
mode: 

void ControlPoint: :enter() getParentModeO . setCurrentControlPoint (this) ; 
Mode. The setting of a mode’s current control point has several implications: 
(1) The mode’s current control point is the new control point. (2) If the control 
point is the default entry, then the history is resumed recursively for the mode, 
if possible. (3) If for a leaf mode the control point is the default entry, then it 
is directly transferred to the default exit. (4) If the control point is the default 
exit, then all parent modes are also set to their default exits recursively. (5) If 
the control point is a non-default control point or a default entry that cannot 
resume a history, then the parent modes are recursively modified such that they 
have no current control point. 

void Mode :: setCurrentControlPoint (ControlPoint* pControlPoint) { 
m_pCurrentControlPoint = pControlPoint ; 
if ((pControlPoint == m_pDe) && (m_pHistory != 0)) 

m_pHistory->setCurrentControlPoint (m_pHistory->m_pDe) ; 
else if ((pControlPoint == m_pDe) && (m_leaf Mode) ) 
setCurrentControlPoint (m_pDx) ; 
else if ( (pControlPoint == m_pDx) && (m_pParent ! = 0) ) 
m_pParent->setCurrentControlPoint (m_pParent->m_pDx) ; 
else if (m_pParent != 0) m_pParent->setCurrentControlPoint (0) ; } 

In this way, we calculate the set of current control points which is required 
to determine the set of enabled transitions of the abstract machine. One of 
the following situations results: Initialization - the set consists of exactly one 
default entry of a non- leaf mode. There is no complete mode configuration, 
and only a transition that initializes the current mode can be enabled. Stable 
- the set consists of exactly the default exits of all modes of the current mode 
configuration from the root mode to the leaf mode. This is a (potentially) stable 
situation that may allow time to pass. Transitions of all hierarchy levels can be 
enabled. Unstable - the set consists of exactly one non-default control point. 
Steps through non-default control points implicitely make up a compound step 
that must not be interrupted, therefore only continuation transitions may be 
enabled next. 



HybridUML Simulation Semantics Definition Selector# uml ■ For the 

coordination of flows, transitions, and abstract machines with respect to the 
simulation semantics of HybridUML, a customized Selector is provided. The 
selector defines an initialization operation init():bool: 
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The initial valuation of the channels has to be given by the environment, 
i.e. from outside the HL 3 specification. Initialization constraints result from the 
initStates of the agent instances within the HybridUML model. They control if 
there is an execution of the model for the given valuation. If all these constraints 
evaluate to true, initialization is completed successfully, otherwise unsuccessfully. 
The operation getSelection(leftFlowPhase:bool): Selection is defined as follows: 

(1) The logical HL 3 time hlStime is adjusted. If the preceding scheduler phase 
was a flow phase, i.e. if leftFlowPhase, then setHL3Time(clustertime,0) of 
TimeService is activated and therefore the model time is updated to the clus- 
ter time. Since model time has increased, on every channel that represents a 
HybridUML signal, false is written, and thus signals are reset. Otherwise, af- 
ter a transition phase ( — ‘leftFlowPhase ), the t\ component is incremented: 
setHL3Time(getHL3Time().tO,getHL3Time().tl+l); 

(2) It is determined if a flow of time would be admissible for the complete model, 
which is denoted by the conjunction flowEnabled = /\" = o isFlowEnablediarrii) 
for all abstract machines. 

(3) The sets try = getTrans(anii) of (identifiers of) enabled transitions are re- 
quested for all abstract machines. 

(4) A set tr = {id G UlLo I £ Transition, t 2 G Transition • {{t\.id G 
trk,t 2 -id G tri) A (ti y^ t 2 => trk A try ) A ( t\.a.readSet U t\.c.readSet) fl 
t 2 -a.writeSet = 0)} is chosen non-deterministically. Thus, a set of transition 
identifiers is chosen that (1) contains up to one transition identifier per abstract 
machine and that (2) contains only identifiers of transitions that are indepen- 
dent of each other, i.e. every possible execution sequence of these transitions is 
allowed. Note that n = \tr\ > 1 is just an optimization of n successive transition 
phases selecting one transition each. If -> flowEnabled , tr y^ 0 is preferred, oth- 
erwise the HybridUML model is deadlocked. 

(5) If tr y^ 0 A flowEnabled, then an “almost” non-deterministic choice is made 
between transitions and flows: Since the scheduler always executes possible tran- 
sitions, as long as there is enough time left before the next flow phase, tr = 0 
may be enforced. 

(6) A visibility attribute att v is created that satisfies att v .t.t(i = hl3time.t,0 A 
att v .t.tl = hlStime.tl + 1, and which has an unrestricted scope att v . scope, i.e. 
every abstract machine or interface module that reads the channels of the writ- 
ten variables is included. The visibility set {att v } is attached to every transition: 
trv = {(f, v) G Transition x VisibilitySet \ t.id G tr A v = {att v }}. 

(7) Finally, a Selection s with s.isFlowEnabled = flowEnabled and s.trans = 
trv is returned by update. 



6 Conclusions 

We have introduced HybridUML, a novel specification formalism for the descrip- 
tion of hybrid systems. HybridUML was defined as a profile extending UML 2.0. 
The main intention of this approach is to facilitate the understanding of the 
formalism for users already familiar with the UML and to utilize existing UML 
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tools for the development of hybrid specifications. The “look-and-feel” of Hy- 
bridUML was illustrated by means of a case study describing a distributed radio- 
based train control system. The semantics of HybridUML has been obtained via 
transformation into the Hybrid Low-Level Language framework HL 3 , thereby 
obtaining semantically well-defined programs which can be executed in hard 
real-time. 

When compared to GIOTTO [HHK03], our HL 3 framework differs in the fol- 
lowing aspects: (1) The HL 3 channel concept - corresponding to GIOTTO ports 
- explicitly supports visibility time stamps and scope. We regard these mecha- 
nisms as very helpful for ensuring consistent data views on different cluster nodes 
in time-triggered systems. (2) The HL 3 framework has been explicitly designed 
to facilitate the automated generation of compilation targets from higher-level 
formalisms. This is reflected by the pre-defined roles and interfaces of abstract 
machines and selector. (3) GIOTTO tasks have a low granularity, corresponding 
to single flows, transitions or transition collections emanating from the same loca- 
tion. Transitions between locations as, for example, between hierarchic states of a 
stateclrart, have to be modeled by GIOTTO mode switches disabling/activating 
“task vectors”. In contrast to this, the HL 3 abstract machines encode behavioral 
models of complete sequential agents; only the flows and actions are separated 
from the abstract machines, in order to optimize scheduling. 

Our current investigations related to semantic issues focus on the respective 
advantages and tradeoffs presented by interleaving semantics versus “true par- 
allelism” interpretations for transitions executed in the same “zero-time phase” . 
The interleaving semantics as defined in this paper and suggested in [AGLS01] is 
compatible with the rely-guarantee verification method [dR + 01, pp. 447] devel- 
oped for shared-variable concurrency. Therefore its utilization gives us the advan- 
tage of well-understood formal concepts and proof theories. A major drawback 
is the fact that interleaved transition execution - while being perfectly well- 
suited on single-processor platforms - cannot easily be distributed for parallel 
execution on several processors: The action of one transition may invalidate the 
firing condition for another transition, so in the worst case - if the write sets 
of the actions for all available transitions overlap with the read sets of all their 
conditions or actions - it is mandatory to execute one transition at a time. In 
contrast to this, Statecharts semantics [DJHP98] defines truly parallel execution 
rules for transitions simultaneously enabled in parallel components: All transi- 
tions available at the beginning of a macro step have the same view on the state 
components within their scope and may fire simultaneously. Their state changes 
become visible in subsequent micro or macro steps. Obviously, these execution 
rules are well-suited for multi-processor scheduling environments. However, this 
advantage has to be paid by increased verification complexity, as, for exam- 
ple, reflected by the problem of racing conditions occurring due to simultaneous 
changes to the same variables in the same step. 

Apart from facilitating the development of hard real-time target systems, our 
transformation strategy supports automated testing of hybrid systems. Here, Hy- 
bridUML agents are used both for the specification of the system under test and 
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for the description of environment behavior to be simulated in specific test exe- 
cutions. While the transformation from HybridUML into the abstract machines 
of HL 3 is the same for target system development and testing, different selector 
instances are used in these two situations: For developing target systems, the se- 
mantic freedom which could be exploited by the selector in the non-deterministic 
choice among possible transition interleavings, as well as the decision when to 
trigger enabled, but non-urgent transitions, should be resolved in a deterministic 
way which can be relied on to meet all periodic schedules. In contrast to this, a 
selector for testing hybrid systems may apply strategies to simulate the greatest 
possible variation of environment behavior, in order to increase the structural 
coverage of the system under test and to check its robustness. A more detailed 
description of testing aspects is currently under preparation [BBPT04] . 

The authors would like to emphasize that HL 3 is not just an experimental 
runtime environment for research purposes. Its current version is used for em- 
bedded systems testing of controllers for the Airbus A380 aircraft family [VS04]. 
Test engines operate with cluster configurations consisting of 3, 5, or more multi- 
CPU PC nodes. 



Acknowledgements. The authors are indebted to Aliki Tsiolakis for her stim- 
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Abstract. We present the Unified Modeling Language (UML) and show how it 
can be applied to development of a new railway interlocking and signalling 
system. Using a simplified example of an interlocking system, we demonstrate 
principles of an object-oriented approach to specifying functional safety re- 
quirements. Starting from an informal specification we create a semi-formal 
specification based on the UML model. Within conclusions we resume advan- 
tages of the presented approach resulting from practical experiences gained in 
the project aimed at development of a new computer-based interlocking system. 



1 Introduction 

The use of electronic components and programmable subsystems changes methods 
usable for development of railway interlocking systems and approaches applied to 
reach required safety. Software development came over evolution from machine code 
through symbolic assembler to high-level procedural and object oriented languages. 
Unfortunately, concurrently with growing level of abstractness complexity of imple- 
mented functions also increased. Higher complexity of systems requires usage of such 
graphical languages and notations from which text notations in implementation lan- 
guages could be derived (automatically or manually) and thus system functions de- 
scribed. One of prospective and promising graphical languages is an object-oriented 
language called Unified Modeling Language (UML). The UML standard [1], [2] 
offers different modelling and visualisation elements to catch and model (i.e. specify) 
system requirements. It provides different diagrams for graphical and textual abstract 
description of system functions, which is independent on hardware/software imple- 
mentation. With the help of a proper software tool, development of object-oriented 
software can become more unambiguous, better structured and complete, doing the 
following: 

Analyze (define system requirements, identify necessary objects and define their 
structure and behaviour using UML diagrams); 

Design (trace requirements to the design, taking into account architectural, 
mechanistic, and detailed design considerations); 
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Implement (automatically generate code from the analysis model, then build and 
run it from within the software tool); 

Test (animate the application on the local host or a remote target to perform de- 
sign-level debugging within animated views). 

Analysis is the software development activity for studying and formulating a 
model of a problem domain and focuses on what is to be done; design focuses on how 
to do it. The paper deals with these first two activities and shows how an object- 
oriented approach (see e.g. [3], [4]) can be applied to development of railway inter- 
locking systems. Informal requirements for control logic of a railway interlocking 
system are generally specified by relevant technical national standards and regula- 
tions. The model presented in this paper respects basic regulations as given by the 
Slovak technical standard [5], but its philosophy and build-up comes out from the real 
project solved by the authors when developing a new railway interlocking system for 
the applications at the German railways. 

The entire model of a real system includes tens of classes and hundreds of states. In 
an effort to explain the used approach and for the sake of better understanding we 
extract basic principles of modelling and present partially simplified example show- 
ing a framework of the most frequently performed activity in the system - setting and 
cancelling the main route. Due to introduced simplifications some of functions cannot 
be considered here, e.g. co-operation with level crossing installations is omitted. Par- 
tial views on discussed problems were published in e.g. [6], [7], [8], [9], [10], 



2 Modelling of Functional System Requirements 

Out-side elements of an interlocking system (signals, point machines, derailer ma- 
chines, technical means for monitoring vacancy/occupancy of track sections, electro- 
magnetic locks etc.) are connected to the control interlocking logic through appertain- 
ing circuits of power interface and the bus as shown in Fig. 1. Interlocking logic on 
the control level co-operates with a control panel and with other interlocking and 
signalling systems, e.g. a section blocking system (SBS), work siding etc. 

The function requirement specification as given below covers both analysis and de- 
sign phases of the development cycle and results in the following set of diagrams: 

Use Case diagrams (describing the functionality of the system - what the system 
will do for the user); 

Class / Object diagrams (describing a static structure of the system); 

Sequential diagrams (behaviour diagrams providing dynamic view at the system, 
specifically interactions among classes/objects); 

Statechart diagrams (behaviour diagrams providing dynamic view at the system). 

Although the UML provides more possible views at the system, mentioned five 
types of diagrams were chosen as predicative enough to describe function require- 
ments. The model was created in the software tool Rhapsody™ ver. 4.0 (a trademark 
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of I-Logix) supporting UML standard 1.3. The tool determines graphical representa- 
tion of visual elements used in diagrams, which is (in some cases) slightly different 
from a UML standard. 






Fig. 1 . Static structure of an interlocking system 

The following principles have been applied when assigning names to individual 
model elements: 



cXxxx Class; 

oXxxx Object; 

avXxxx Variable attribute; i.e. an attribute that may have 

different values in time; 

apXxxx Project attribute; i.e. an attribute whose value is 

invariant and depends on an individual application; 
kXxxx Value of an attribute; 

evXxxx Event or method triggered by an event with this name; 

mXxxx Primitive operation. 



Since presented parts of the model comes out from the real project elaborated for a 
German customer, the names of classes, objects, attributes, events and states used in 
the following text have a form of abbreviated original German expressions. Except 
for the Use Case diagram (described totally in English), the model as it is should be 
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well readable by German speaking professionals from the railway domain. For other 
English speaking readers key names and/or abbreviations are properly explained 
continuously in the text. 



2.1 Use Case Diagram 

Fig. 2 shows the Use Case diagram of the considered interlocking system. The dia- 
gram defines a system boundary, use cases, actors and mutual relations between these 
elements. Actors represent external entities - a Station Dispatcher and co- 
operating technical systems (SBS, Work Siding, etc.). Relations between a Sta- 
tion Dispatcher and individual use cases (Control of Train Running, 
Control of Shunting Operation, Control of Points Movement, 
etc.) are represented as bidirectional communication associations, i.e. a Station 
Dispatcher can activate these activities and is informed about them. Other actors 
are cooperating systems that have bidirectional communication association with activ- 
ity Control of Train Running. Another associations may be defined be- 
tween individual activities (use cases), e.g. between the Control of Outgoing 
Routes and the Control of Train Running there is an association relation- 
ship «generalization»; activity the Control of Entry Routes inherits 
properties of the Control of Train Running; between activities the Con- 
trol of Outgoing Routes and the Route Setting there is an association 
relationship of <<include>> indicating that a use case is also used by other use 
cases. 



2.2 Class Diagram 

The Class Diagram makes description of a static structure of the system possible. In 
Fig. 3 a simplified class diagram for the interlocking logic considered on the control 
level is shown. For the sake of lucidity and readability only those classes are depicted 
in the diagram that are necessary for description of activities discussed later in the 
text without showing their mutual relations and multiplicity. 

The package Steuerebene (Control Level) includes packages Bedienung 
(Operation), Fahrstrasse (Route), Strecke (Line), Weiche (Points), 
Gleisabschnitt (Track Circuit), Signal (Signal) and Schluesselsperre 
(Key Locking). 

The package Bedienung includes the class cHilf sbedienung (Emergency 
Operation) and cBedienung (Operation) that generate one object each. These ob- 
jects enable both standard and emergency operation of an interlocking system (send- 
ing messages that contain commands for setting main or shunting routes, commands 
for changing states of outdoor elements; receiving messages that contain information 
on conditions of main or shunting routes, information on conditions of outdoor ele- 
ments etc.). 
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Fig. 2. The Use Case Diagram 

In the class cFahrstrasse (Route) the whole process of setting and releasing 
the main route is implemented. This implementation also includes control of all ele- 
ments assigned by project (application) to the particular main route. Each entry and 
outgoing main route is represented by one object of this class. 

The class cVWFahrstrasse (Route Management) generates one object that par- 
tially realises logical relations between individual main routes with one another and 
relations between main routes and shunting operation (incompatibility between 
routes). The object receives and processes demands for setting and releasing the main 
routes and shunting operation as entered through the control panel. At the same time 
only one main route may be in the process of setting. If other demands for setting 
another main routes are received during this process they are memorized and proc- 
essed later after the setting process of the previous main route is over. 
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Fig. 3. The Class Diagram 



The class cRangierbereich (Shunting) generates as many objects as many 
shunting areas the railway station is divided to. An object of the class cRangier- 
bereich checks all conditions to be fulfilled to permit or cancel shunting operation 
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ill a given part of the station. Shunting operation may be realised only if no main 
route is set or being set. If the station is switched over to the mode of shunting opera- 
tion, no main route may be set. 

Each line track entering the station is represented by one object of the class 
cBlockpassung (Block Adaptation). The class cVWBlockpassung (Block 
Adaptation Management) represents data interface between an interlocking system 
and a section blocking system, or another interlocking system. 

Each electrically operated switch (points) is represented by one object of the class 
cWeiche (Points). An object of the class cWeiche processes messages on the state 
of its related points (points position - right, left, no end position, force-opening of the 
points, points failure). Each change of the state is reported to an object of the class 
cBedienung and to objects of the class cFahrstrasse. Objects also process 
commands for marking and unmarking points in dependence on the role they perform 
in the main route, and also commands related to centralized and local control of 
points. 

The class cVWWeiche (Points Management) generates one object that processes 
incoming telegrams about a changed points condition and generates corresponding 
events to individual objects of the class cWeiche. In addition, this object sequen- 
tially controls point machine operation. A maximum number of points concurrently 
being moved can be defined in project works. If another demands for moving points 
are received they are memorized and processed after the actual points movement is 
over. 

The class cVWNahbedienung (Local Operation Management) generates one ob- 
ject that receives telegrams from locally operated points and generates corresponding 
events to objects of the class cWeiche. 

Each electrically operated lock is represented by one object of the class 
cSchluesselsperre (Key Locking). An object of the class cSchluessel- 
sperre processes messages on the state of its related lock, messages on handling the 
lock buttons (request button, acknowledgement button) and marks (unmarks) the lock 
according to the role it performs in the main route. Each change of the state is re- 
ported to an object of the class cBedienung and to objects of the class cFahr- 
strasse or objects of the class cRangierbereich. Objects of the class cFahr- 
strasse or objects of the class cRangierbereich are used to control blocking 
or unblocking of locks. 

The class cVWSchluesselsperre (Key Locking Management) generates one 
object that receives incoming telegrams from locks (info on key state and buttons 
state) and generates corresponding events to individual objects of the class 
cSchluesselsperre. In addition, this object processes commands for blocking 
and unblocking the keys coming from objects of the class cSchluesselsperre. 

Each stand-alone signal is represented by one object of the class cSignal (Sig- 
nal). An object of the class cSignal processes reports on signal indications given at 
the related signal; marks (unmarks) the signal according to the role it performs in the 
main route, controls distant signals in accordance with signal indications of the main 
signals and also processes commands from objects of the package Bedienung and 
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objects of the class cFahrstrasse for turning on the required indication at the 
signal. The class also implements processing of messages and commands for different 
kinds of signals (stand-alone distant signals, main signals, indicators etc.). 

The class cVWSignal (Signal Management) generates one object that processes 
telegrams coming from signals and generates corresponding events to individual 
objects of the class cSignal. In addition, it receives and processes commands for 
changing signal indication coming from objects of the class cSignal. 

Each track section is represented by one object of the class cGleisabschnitt 
(Track Circuit). An object of the class cGleisabschn.it processes messages on 
vacancy or occupancy of its related track section; marks (unmarks) a track section 
according to the role it performs in the main route and blocks a track section (techni- 
cal occupancy of a track section). Each change of the state of a track section is re- 
ported to objects of the classes cFahrstrasse, cBlockpassung and cBedi- 
enung. 

The class cVWGleisabschnitt (Track Circuit Management) generates one ob- 
ject that processes telegrams coming from technical means used to monitor vacancy 
of track sections (failure message; a track section has been vacated in a certain direc- 
tion; a track section has been occupied in a certain direction) and generates events to 
corresponding objects of the class cGleisabschnitt. 

Each class is a category or a group of entities having similar features and the same or 
similar behaviour. Behaviour of entities in the given class is described by specific 
operations (methods). Features of entities in the given class are described by attrib- 
utes. Fig. 4 shows a closer specification of the class cWeiche. 

2.3 Sequential Diagram 

Sequential diagrams are used to describe co-operation of system objects with respect 
to time. They should be created for all possible scenarios related to interlocking sys- 
tem operation. 

Fig. 5 shows a part of co-operation of objects generated by the class cBedi- 
enung, cVWFahrstrasse, cFahrstrasse, cBlockpassung, cWeiche, 
cGleisabschnitt, cSchluesselsperre and cSignal in the process of 
setting and releasing the main route. Objects mutually co-operate via message ex- 
change; lines with simple arrows represent asynchronous messages (events) and hori- 
zontal lines with filled-in arrowheads represent synchronous messages (primitive 
operations). 

After giving a command for setting the main route an object of the class cBedi- 
enung sends the event evFsStellen (pFsNum, pZiel ) to an object of the class 
cVWFahrstrasse. The event contains information on a number of the required 
main route (parameter pFsNum) and on its destination (parameter pZiel). The 
received number of the main route is analysed and helps an object of the class 
cVWFahrstrasse to decide whether a single main route (entry, outgoing) or a 
complex main route (transit through the station) is concerned. If the complex route is 
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Steuerebene::Weiche: :cWei che 

-avWeiSperre : BYTE 
-avWeiBedienung : BYTE 
-avWeiLage : BYTE 
-avWeiFweg : BYTE 
-avWeiDweg : BYTE 
-avWeiFweg Flschutz : BYTE 
-avWeiDweg Flschutz : BYTE 
-avLezte Betel : BYTE 
-apWeiNum : BYTE 
-apGIabNum : BYTE 

-apWeiGrindlage : BYTE 

-mlstWeiLage(BYTE pSolllage):OMBoclean 
-mlstAnf Li nks Lage Q : OMBcolean 
-mlstAnf Rechtslage() : OM Boolean 
-mlstWei Gekemzeichnet():OMBoolean 
+evWeiAbkennzeictinung(BYTE pAveck) 
+evWeiKemzeichrung(BYTE pZweck) 
+evWei FembedienungQ 
+e\Wei NahbedienLngO 
+evWeiEntspenen() 

+evWeiSperrer() 

+evWeiLage(BYTE pLage) 

+evWei GruidlageStellenQ 
+evWei Stellen(B YTE pSolllage) 
+evNbStellen() 



Fig. 4. The Class cWeiche 

the case it is realised by consecutive setting the single routes it consists of. For each 
single main route an object of the class cVWFahrstrasse generates the event 
evFsAnf orderung (pZiel ) . If the required route may be set (there is neither 
another main route nor shunting route to endanger it) then an activated object of the 
class cFahrstrasse generates events to individual objects of main route elements 
(objects of the classes cWeiche, cGleisabschnitt, cSchluesselsperre, 
cSignal) with a command for marking them according to the role that each element 
plays in the main route. This role is defined in project works (attributes of the class 
cFahrstrasse) and the transmitted event includes it as a parameter pZweck. For 
instance, for objects of the class cWeiche the event evWeiKennzeich- 
nung (pZweck) is generated with the parameter pZweck having one of possible 
values: 



kWeiFweg, for points being a part of the main route; 

kWeiDweg, for points being a part of protection distance of the main route; 

kWeiFwegFlschutz, for points representing flank protection for the main 

route; 

kWeiDwegFlschutz, for points representing flank protection for protection 
distance of the main route. 

Information on the fact that the process of setting the main route was started is 
given to an object of the class cVWFaf rstrasse by the event evFs- 





The Use of UML for Development of a Railway Interlocking System 



183 



cVWFahrstrasse cBlockpassung cGleisabschnitt cSignal 

cBedienung cFahrstrass© cWeiche cSchluesselsperre 



t vFsZusta| 
e\ FsAktuali: 



0 vFsSt©lfen(pFsNiJrn. pZiel) 



evFsAnfgrderung(p 



hd(pFsNu 



^iQrung(pff sNum i pl\ 
evStrAnj 



evSspKerjnzQichnurig(pZweck) 



evSigKen 



gvWeiterrt 



R. 



pZustajid) 

ustand) 

j orderungflpFsNum, 

evFsSti Zulassurt«() 



evWeiSti !llen(pSol 
ev WeiLage/ .enderunJ () 



ImlstWeiL agQ(pSol[ [ l age) 
|evWeiUel|ierwachur|gPositiv()| 



pel) 
evWeiKernzei 



evGlabKannzeichnli 



R 



IstSigZu 



pilstGlablfrei(pRich 



evFsVor; 



bvEndsSi 



knlstSigZu 



ichnii i! 



ZQichnurig(pZwecM) 



stand(pZui stand) 



pilstSspFpstgelegtQ 



mlstWeiHage(pSolj| 



hlstStrH^ltFall() 

gUeberwhchungPo(sitiv() 



evSspFreigeben() 



pFreigeb4n() 



vSigHpat©llen(pS(tllGschw, 



stan d(pZil stand) 



tavEndeSibStellenQ 



g(pZw©> 

ng(pZwgt 



4 ) 



kk) 



bZiel) 



lage) 



ung) 



age) 



pSolIZusafrz) 



evSiq/'lenderunq l 



Fig. 5. Example of a Sequential Diagram (Setting a Main Route) 

Zustand (pFsNum, pZustand) and to an object of the class cBedienung by 
the event evFsAktualisierung (pFsNum, pZustand) . 

Setting an outgoing route requires permission from a section blocking system of 
the target track. For this purpose an object of the class cFahrstrasse generates 
the event evStrAnf orderung (pFsNum, pZiel ) . The parameter pZiel may 
get a value: 

kUndef iniert, if a train goes to a work siding, that has no relation to the 
interlocking system (in the model referenced as Anst) or a train goes to the 
adjacent station; 
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kAwanstN, if a train goes to the work siding, that is dependent on the inter- 
locking system (in the model referenced as Awanst); where N represents an 
Awanst number at the line. 

If conditions required for a train to leave the station are fulfilled then a relevant ob- 
ject of the class cBlockpassung will transmit the event evFsStrZulassungQ 
to the object oFahrstrasse [avFsNum] . 

The event evWeiStellen (pSolllage) containing a command for switching 
points to the required position is transmitted to all objects of the class cWeiche, 
defined by the project for this main route. If any of the points change their position, 
an object of the class cWeiche related to these points generates the event evWei- 
LageAenderung ( ) to objects of the class cFahrstrasse. This event doesn't 
contain information about points position, it only informs about the fact that some of 
points changed their condition. If such a change can be relevant to an object of the 
class cFahrstrasse then this object checks a required position of the points by the 
primitive operation mlstWeiLage (pSolllage) . Check of points position is 
positive (successful) if the operation mlstWeiLage (pSolllage) returns the 
value true. If all points were checked successfully, then the event evWeiUeber- 
wachungPositiv ( ) is generated. 

The similar procedure for checking other elements of the main route must also be 
realised before giving a command for turning a proceed aspect at the start-signal (or 
at the intermediate signal) or before giving a command for release of a start-key (in 
the case of a route to Anst). The primitive operation mlstSig- 
Zustand (pZustand) is used to check conditions of signals in the station - stop 
aspect at the start-signal, intermediate signal, and target signal and at signals playing 
the role of flank protection of the main route. The primitive operation 
mlstSspFestgelegt ( ) is used to fix keys; the primitive operation mlst- 
GlabFrei (pRichtung) is used to check vacancy of track sections whilst there is 
no importance in which direction they became vacated. The value of the parameter 
pRichtung = kUndef iniert is unimportant as well. The primitive operation 
mlstStrHaltFall ( ) is used to check a correct position of elements included in 
the first line section which a train runs on. 

In the case of the positive result of these checks (an object of the class cFahr- 
strasse generates the event evFsVorSigUeberwachungPositiv ( ) to itself) 
the event evSigHpStellen (pSollGschw, pSollZusatz) is generated to 
all objects of the class c Signal, that take a share in setting signal aspects for the 
main route being in the process of setting. The parameter pSollGeschw carries 
information on velocity required in sections behind the signal; the parameter pSoll- 
Zusatz carries information on velocity that is to be expected at the next signal. 

If a train leaves for the work siding having no relation to the station (Anst), giv- 
ing proceed aspect at the start-signal must be preceded by a command for unblocking 
a start-key (evSspFreigeben ( ) ) that an engine-drive carries about. 

Once proceed aspect is being given at the start-signal, setting the main route is 



over. 
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Fig. 6. Example of a Sequential Diagram ( Releasing a Main Route) 

The sequential diagram in Fig. 6 shows a part of how objects of the classes cBe- 
dienung, cVWFahrstrasse, cFahrstrasse, cBlockpassung, cWeiche, 
cGleisabschnitt, cSchluesselsperre and cSignal cooperate in releas- 
ing an outgoing main route. 

If the main route is being set then continuous check of fulfilment of conditions for 
giving proceed aspect at the start-signal (eventually at the intermediate signal) must 
go on, e.g. if a train enters a section behind the start-signal then the state of this track 
section is changed and an object of the class cGleisabschnitt, assigned to this 
track section, generates the event evGlabAenderung ( ) . The primitive operation 
mlstGlabBelegt (pRichtung) returns the value true, an object of the class 
cFahrstrasse representing the set main route evaluates breaking conditions nec- 
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essary for giving proceed aspect at the start-signal, generates the event evFsNach- 
SigUeberwachungNegativ ( ) and gives a command for giving stop aspect at 
the start-signal (the event evSigHpStellen (pSollGschw, pSollZusatz ) - 
the release process of the main route is started. 

Release of the main route is realised in two phases. In the first phase lock of route 
elements is cancelled, in the second phase elements making flank protection are re- 
leased. 

Route elements may become unlocked provided that stop aspect is given at the 
start-signal, eventually at the intermediate signal, and sequential release occurs. Se- 
quential release is based on continual occupying and vacating the track sections of the 
route. Since direction of train movement is important in evaluation of continuality, 
the parameter of primitive operations mlstGlabBelegt (pRichtung) and 
mlstGlabBelegt (pRichtung) has the value kSteigend or kFallend. 
Detection of continual train running results in generating the event evFwegKonti- 
nuierlicheFreigabe ( ) . Giving stop aspect at the start-signal, eventually at the 
intermediated signal, is checked by the primitive operation mlstSig- 
Zustand (pZustand) . If these checks are positive (i.e. conditions are fulfilled), 
events are generated and transmitted to particular objects to unmark their roles per- 
formed in the main route (objects of the classes cWeiche, cGleisabschnitt, 
cSchluesselsperre, cSignal). The events evWeiAbkennzeich- 

nung (pZweck) , evSspAbkennzeichnung (pZweck) , evGlabAbkenn- 
zeichnung (pZweck) and evSigAbkennzeichnung (pZweck) are con- 
cerned. 

Information on release of the main route is given to an object of the class cBe- 
dienung (by the event evFsAktualisierung (pFsNum, pZustand) ). 

After the target section has been occupied, the event evStartTimeDwa ( ) is 
generated. It triggers measurement of safety time that is used to cancel lock of protec- 
tion distance. End of this measurement is evaluated by the primitive operation mlst- 
TimeDwa ( ) . If this operation returns the value true and occupancy of no track 
section included in protection distance is indicated then events for unmarking ele- 
ments in protection distance are generated. If a target track section has been vacated 
during safety time measurement, measurement is untimely finished, the primitive 
operation mlstTimeDwa ( ) returns the value false and lock of protection dis- 
tance must be cancelled using emergency means. 

Information about the main route being released is given to an object of the class 
cVWFaf rstrasse by the event evFsZustand (pFsNum, pZustand) and to 
an object of the class cBedienung by the event evFsAktuali- 
sierung (pFsNum, pZustand). 

2.4 Statecharts of the Class cFahrstrasse 

The statechart diagram is another kind of diagram that is used to describe functional 
properties of the system. The state diagrams use the following convention to specify 
transition from one state to another: trigger [condition] /action 
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Fig. 7. Example of a Statechart Diagram: Statechart of the class cFahrstrasse 

Fig. 7 shows the statechart diagram of the class cFahrstrasse. After initialisa- 
tion the system enters the state RuheZustand by default. An object of the class 
cFahrstrasse remains in this state when waiting for a command for setting the 
main route (represented by the event evFsAnforderung ( ) ). Entering this state, all 
variable attributes of the class cFahrstrasse are set to their default values, e.g. the 
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attribute avFsZustand remembering the state of the main route is given the value 
kRuhezustand - the main route is in the idle state. 

The statechart diagram is designed in such a way that it is possible to go regularly 
from any state back to the state RuheZustand. The states Elemente_Kenn- 
zeichnung, Weichen_Stellen, SspRuecknahme and Elemente_Ab- 
kennzeichnung are passed through to the next state executing a code when enter- 
ing the state. In the state Strecke_Zulassungspruef ung automatic return to 
the state RuheZustand is possible if conditions for setting the route are not fulfilled 
(the event evFsStrAblehnung ( ) ). It is possible to get back from the states Wei- 
chen_Ueberwachung, Fs_VorSig_Ueberwachung, Ssp_Freigeben, 
Signal_Stellen to the state RuheZustand automatically if conditions for 
setting a route are not fulfilled (the event evFsAuf loesung ( ) ) or a station dis- 
patcher has given a command for cancellation of route setting. If a station dispatcher 
gives a command for release of the main route without train running then an object of 
the class cBedienung generates the event evFsRuecknahme ( ) (not visible in 
this diagram). After its reception an object of the class cFahrstrasse generates 
the event evFsAuf loesung ( ) and we get back to the state RuheZustand. 

The state Fs_NachSig_Ueberwachung may be left for the state RuheZustand either 
after reception of the event evFsRuecknahme() or after evaluation of regular train 
running (passing through the states FwegElemente_Abkennzeichnung, Dweg_Be- 
legung_Auswertung, FwegElemente_Abkennzeichnung). The states FwegEle- 
mente_Abkennzeichnung, Dweg_Belegung_Aus-wertung, Signal_Ruecknahme, 
Strecke_Ruecknahme may also be left after a station dispatcher has given a command 
for release of the main route using emergency means (the event evFsHilfsaufloesungO 
generated by an object of the class cHilfsBedienung). 

If the requirement for setting a route is correct (the primitive operation 
mlstFsAnf orderungKorrekt ( ) returns the values true), then an object tran- 
sits from the state RuheZustand to the state Elemente_Kennzeichnung, 
otherwise the requirement is refused and the primitive operation 
mSendFsZustand ( ) is triggered, having the following implementation: 

oBedienung->GEN (evFsZustand (apFsNum, avFsZustand) ; 

oVWFahrstrasse- 

>GEN (evFsAktualisierung (apFsNum, avFsZustand) ; 

After entering the state Elemente_Kennzeichnung, the events are generated to 
mark objects of those classes that belong to elements related to the main route, e.g. 
the following code is used to mark points: 

BYTE i; 

for (i=0; i<kWeiMax; i++) 

{ 
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if (apWeiZweck [i] ! =kUndef iniert) 

oWeiche [ i ] ->GEN (evWeiKennzeichnung (apWeiZweck [ i ] ) ; 

} 

GEN (evWeiter ( ) ) ; 

The constant kWeiMax represents the maximum number of switches in the station 
and the constant kUndef iniert means the switch is not related to the main route. 

When setting an outgoing main route, an object of the class cFahrstrasse 
must cooperate with an object of the class cBlockpassung. This cooperation can 
be found in the state Strecke_Zulassungspruef ung that comprises other sub- 
states. In this state conditions for train leaving the station are being checked, i.e. 
transmission of single-line permission, reception of return indication after the last 
train, vacancy of the first line section, active giving proceed aspect at the first block 
signal if it hasn't an individual distant signal. In the case a train leaves for the work 
siding having dependency on the interlocking system (Awanst), conditions of the 
work siding are also to be checked. Cooperation with the line is not necessary in this 
state if an entry main route is being set. If conditions related to the line are fulfilled, 
the event evFsStrZulassung ( ) is generated and route setting goes on; other- 
wise the event evFsStrAblehnung ( ) is generated, an object of the class 
cFahrstrasse enters the state Elemente_Abkennzeichnung (generates 
commands for unmarking elements) and an object gets back to the state Ruhe- 
Zustand. 

In the state Weiche_Stellen commands are generated to move points relevant 
to the main route: 

BYTE i; 

for ( i=l ; i<=kWeiMax; i++) 

{ 

if (apWeiLage [i] ! =kUndef iniert) 

oWeiche [i] ->GEN (evWeiStellen (apWeiLage [i] ) ) ; 

} 

GEN (evWeiter ( ) ) ; 

The attribute apWeiLage is of the array type. The number of elements represents 
a number of points operated in the railway station and each element may have a 
value: 



kUndef iniert, if points position is not defined for the main route; 
kRechts, if position “right” is required for a given main route; 
kLinks, if position “left” is required for a given main route. 

Fig. 8 shows the statechart of cFahrstrasse . Weichen_Ueberwachung. In 
this statechart a correct end position of the points related to the main route is checked. 
If all relevant points are in the required position, then the primitive operation mWei- 
FueZ ( ) returns the value true. 
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Fig. 8. Statechart of cFahrstrasse . Weichen_Ueberwachung 



The primitive operation mlstWeiStoerung ( ) returns the value true provided 
that some of the points related to the main route are faulty (e.g. end position of points 
has not been reached within a given time limit). In that case the system enters the 
state Weichen_Hilf sbedienung, where emergency operation of the points is 
enabled. If emergency operation of the points is successful, the event 
evWeiHlbPositiv ( ) is generated; otherwise the event evFsAuf loesung ( ) is 
generated. The serial state Ruecknahme_Wartung makes a command for main 
route release possible (command from a station dispatcher). 

In the state Fs_VorSig_Ueberwachung (Fig. 7, Fig. 9) those conditions are 
checked that are necessary for giving proceed aspect at the start-signal, eventually at 
the intermediate signal. It is checked whether actual state of all elements (signals, 
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Fig. 9. Statechart of cFahrstrasse . Fs_VorSig_Ueberwachung 



locks, track sections, points and line) related to the main route corresponds to the 
required states. The result of check is positive if the primitive operations mSig- 
FueZVor ( ) , mSspFueZVor ( ) , mGlabFueZ ( ) , mWeiFueZ ( ) , mStrFueZ ( ) 
return the value true, e.g. the implementation of the primitive operation mWei- 
FueZ ( ) that checks points conditions is as follows: 

BYTE i; 

for ( i=l ; i<=kWeiMax; i++) 
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{ 

if ( (apWeiLage [i] ! =kUndef iniert ) && (avWeiHlb [i] ==kKeineHl 

b) ) 

{ 

if ( ! rWeiche [ i ] ->mIstLage (apWeiLage [ i ] ) ) 
return false; 

} 

} 

return true; 

For elements that do not pass over the checks the emergency operation is auto- 
matically required. If such an emergency operation is successful, then it goes on with 
another problematic element (if there is any). Emergency operation of the particular 
element is recorded (e.g. for the points the attribute avWeiHlb of the array type is 
used; the value kKeineHlb means that emergency operation has not been used) and 
other emergency operation of this element for a set route is not possible. If emergency 
operation of some of elements fails (the result of checks remains negative), the proc- 
ess of setting the route is automatically finished. 

If conditions for setting the main route are fulfilled and there is a key specified in 
the project as a constant kStart (apSspZweck [i] =kSspStart) , then a 
command for release of this key is given. Sequence of activities related to release of 
the start-key is implemented in the state Ssp_Freigeben (see Fig. 7). 

In the state Signal_Stellen (Fig. 7) there are activities included that relate to 
generating commands for giving stop aspect at the target signal and proceed aspect at 
the intermediate signal and at the start-signal. Transmission of the command is fol- 
lowed by the check whether the command was really executed. These activities are 
realized sequentially from the target signal to the start-signal (Fig. 10). 

The role of signals in a main route is projected as an attribute apSigZweck. It is 
of the array type and number of its elements corresponds to number of signals in the 
station, e.g. an element of this array may have the value: 

kUndef iniert , if the signal is not related to the main route; 
kSigZiel, if the signal is defined as a target signal for the main route; 
kSigZwischen, if the signal is defined as an intermediate signal for the 
main route; 

kSigStart, if the signal is defined as a start-signal for the main route; 
kSigFwegFlschutz, if the signal makes flank protection for the main 
route; 

kSigFwegFlschutz, if the signal makes flank protection for protection 
distance of the main route; 

kSigStartVorZiel, if the signal is defined as a start-signal for the main 
route and concurrently also as a distant target signal; 
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Fig. 10. Statechart of cFahrstrasse . Signal_Stellen 

In the state Fs_NachSig_Ueberwachung (Fig. 7) conditions for giving pro- 
ceed aspect at the start-signal, eventually at the intermediate signal, are being 
checked. If they are not fulfilled, a command for giving stop aspect at the start-signal 
is given, the element, which is the cause of difficulties, is identified and its emergency 
operation is requested, e.g. at the start-signal a call-on aspect may be given. Once 
proceed aspect is given at the start-signal, no emergency operation of track sections is 
possible. Occupancy of the section (including a technical occupancy) will cause tran- 
sition to the state FwegElemente_Abkennzeichnung and the evaluation proc- 
ess of train running continuality is started. If technical occupancy causes stop aspect 
at the start-signal then the station dispatcher must initiate call-on aspect in order to 
realize train running. Conditions for giving proceed aspects are checked in two steps: 

1 st step - when entering the state; 

2° step - after reception of the message about a changed state of some elements in 
the station. 

In the state FwegElemente_Abkennzeichnung those conditions are checked 
that are necessary to release the main route. Train movement is considered continual 
if: 
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Occupancy of all sections contained in the route (apart from a target section) 
was recorded respecting correct direction according to the project; 

Occupancy of the target section in projected direction was recorded; 

Vacancy of all sections of the route (apart from a target section) in correct di- 
rection was recorded. 

If train running has been evaluated to be continual and relevant signals do not give 
proceed aspects, events for unmarking elements related to the route are generated. For 
entry routes return indication is transmitted after a train entered the station. Return 
indication may be transmitted provided that the track section behind the entry signal 
is vacant and the entry signal (in this case a start-signal) gives stop aspect. Transmis- 
sion is realised in such a way that an object of the class cFahrstrasse generates 
the event evStrRueckblock ( ) to an object of the class cBedienung (not visi- 
ble in the diagram). 

In the state Dweg_Belegung_Auswertung conditions for cancellation of pro- 
tection distance lock are being checked (vacancy of track sections contained in pro- 
tection distance, completed measurement of safety time). If the target signal is con- 
currently a start-signal (passage through the station) then measurement of safety time 
is not required. If conditions for cancellation of protection distance lock are fulfilled, 
the event evDwegFrei ( ) is generated and an object of the class cFahrstrasse 
enters the state DwegElemente_Abkennzeichnung, where events are generated 
containing a command for unmarking elements related to protection distance of the 
main route. 

If the start-signal or intermediate signal gives proceed aspect and a command was 
given for release of the main route (the event evFsAuf loesung ( ) ), then an object 
of the class cFahrstrasse enters the state Signal_Ruecknahme. In this state 
commands are generated for giving stop aspects at these signals and their execution is 
checked. The main route becomes released after safety time lapses away (time is 
different from safety time for protection distance). If all track sections of the locked 
main route are vacant when safety time has lapsed away, the event evWeiter ( ) is 
generated and an object of the class cFahrstrasse enters the state 
Strecke_Ruecknahme. If occupancy of a track section contained in the route is 
recorded during measurement of safety time, the event evFwegBelegt ( ) is gener- 
ated and an object of the class cFahrstrasse enters the state FwegEle- 
mente_Abkennzeichnung. Release of the main route by train running is ex- 
pected. 

If any activities related to blocking the line or elements in the adjacent station were 
performed in the process of route setting, now this blocking must be cancelled. Ac- 
tions related to this activity are performed in the state Strecke_Ruecknahme. 

If a start-key was released in route setting, then the main route may be released not 
earlier than the key was locked and fixed. Actions related to this activity are per- 
formed in the state Ssp_Ruecknahme. 
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Fig. 11. Statechart of cWeiche 



2.5 Statechart of the Class cWeiche 

Fig. 11 shows the statechart diagram of the class cWeiche, which consists of three 
serial states. In the state Weiche_Betrieb there is reception of commands for 
marking (evWeiKennzeichnung ( ) ) or unmarking (evWeiAbkennzeich- 
nung ( ) ) of the points according to the roles played in the main route. The points 
may concurrently be related to more main routes (e.g. points may be a part of one 
route and represent flank protection for another route). In the state Weiche_Lage 
messages about the actual states of points or their failures are received. Information 
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on a changed state of the points is sent to all objects of the class cFahrstrasse. 
The points may be controlled in a centralized way (an object is in the state Wei- 
che_Fernbedienung), in a local way (an object is in the state Wei- 
che_Nahbedienung) or may be blocked (an object is in the state Wei- 
che_Sperre). If the points are blocked, electrical switching is impossible. Points 
may become controlled locally only if they are not marked as used in a main route 
( [mIstWeiGekennzeichnet==false] ). Indications on points position given 
at the panel of local control are active only if local control is activated. After recep- 
tion of a command for moving points from the panel of local control the required 
position must be determined (opposite position to the actual one). If centralised con- 
trol of points is activated, the points may be controlled by commands from a station 
dispatcher (individual control) or by commands from objects of the class cFahr- 
strasse (automatic control according to the requirements of the main route). The 
station dispatcher may control the points individually only if they are not marked as 
being used in a main route. If the points have a default position defined (the attribute 
apWeiGrundlage), they will always move back to this position provided that they 
are not marked for usage in a main route or their local control is not activated. Com- 
mand for switching over (moving the points to the opposite position) is accepted only 
if the points are in a different position than required, the switch section is vacant, 
force open is not recorded and the points are fault-free. 



3 Summary and Outlook 

The main aim of the paper was to explain how object-oriented approach could be 
applied to development of a new railway interlocking system. The model discussed 
above represents a simplified and slightly modified version of the model that was 
elaborated as a functional specification for the new railway interlocking system being 
developed and implemented in German railways. Using practical experiences from 
applying the UML in the field of designing railway applications, we can see several 
advantages that are worth mentioning here: 

At the beginning a customer presented a set of incomplete initial requirements in 
the form of the “wish list” (ger. Lastenheft) representing an informal function re- 
quirements specification. In comparison with this document the final UML-based 
function requirements specification is more unambiguous, complete and well- 
structured; 

Created model may be used as a basis for communication of (international) devel- 
opment teams working over the common project; this also holds good for subjects 
active in the process of safety assessment and safety approval of a newly developed 
system. In our case the UML-based model has been accepted by relevant Railway 
Authority (EBA); 

Creation of the UML-based model is generally unthinkable without support of a 
proper CASE tool; what’s more, created specification is generally independent on 
particular programming language (linkage will be of use first when source code is 
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automatically generated, i.e. in the process of forward-engineering). Although authors 
of this paper were not involved in the process of coding (translating semantics into 
full production-quality code), according to practical experiences of involved software 
workers at least 90% of the generic core of the interlocking logic was automatically 
generated using the mentioned software tool. For automatic code generation two 
types of diagrams were used - sequence and statechart diagrams; 

Another advantage consists in tool- supported automatic generation of documents 
that makes unification of documentation principles possible; 

Functionality of the designed model can be verified using animation; with possibil- 
ity to present a prototype of the system to a customer immediately after the specifica- 
tion phase is completed; 

In comparison with informal specifications and/or specifications based on other 
formalisms, maintenance and realisation of later changes and modifications of UML 
models is much easier. In addition, general availability and understandability of the 
standard UML is an undoubted advantage, together with minimum cost needed to 
learn it and permanent support of the UML standard from the main providers of soft- 
ware tools. 

At present support of tools and their implemented methods is quite sufficient for 
design, simulation and transfer to implementation, unfortunately the same cannot be 
said about proofs. Much effort is made to solve the task of checking correctness of 
UML-based specifications and possibilities of their verification. The UML standard 
still belongs to the group of semi-formal methods that are not able to provide mathe- 
matical (calculated) proof about ability or inability of the system to enter a certain 
hazardous state or recover safety state under abnormal situations. What’s more, us- 
ability of UML specifications is restricted to modelling safety function requirements, 
not safety integrity requirements. 
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Abstract. This is the introduction to the chapter on the subject area 
Petri Nets and Related Approaches in Engineering. After a short report 
on experiences in this subject area during the DFG 1 Priority Program 
we introduce and survey the papers of this chapter. Furthermore, we 
indicate that the work done in the subject area provided answers to 
important questions and - more importantly - helped to identify the 
state-of-the-art in the field as well as gaps to be filled by further research 
and development activities. 



1 The Subject Area 

At the beginning of the Priority Program Integration of Software Specification for 
Applications in Engineering five years ago, Petri Nets and Process Description 
Languages were installed as two independent subject areas. It turned out after a 
short time that both areas have a strong intersection. Therefore, these two areas 
joined soon - resulting in the subject area with the title Petri Nets and other 
Process Description Languages. 

The subject area organized (almost) annual workshops, often in connection 
with a general assembly of the project partners to ensure that many project 
participants were able to participate. The main issue of these workshops was 
to exchange ideas rather than to present finished results, thus allowing the re- 
searchers from the various project groups to contribute to the development of 
other approaches, to reflect their ideas with other experts and to mutually profit 
from the results as early as possible. This way, cooperation and exchange of ques- 
tions (rather than only answers) was possible. The proceedings of the workshops 
have not been and will not be published, but most of the presented material is 
now comprised in the papers of this chapter. 

Although Petri nets play a particular role in this subject area, many projects 
of the priority program not engaged in Petri net research took part in the activ- 
ities of the subject area. It might be remarkable that in particular the project 

1 Deutsche Forschungsgemeinschaft (German Research Council) 



H. Ehrig et al. (Eds.): INT 2004, LNCS 3147, pp. 199-205, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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groups from engineering departments were interested in this topic - thinking in 
processes is apparently more developed in engineering than in computer science. 
Since not all participating research groups document their work with a paper in 
this chapter, the groups that contributed to the subject area are listed below (in 
alphabetic order): 

DisPA led by B. Vogel-Heuser (Uni Wuppertal), P. Gohner (Uni Stuttgart) 
(see the contribution of K. Fischer et al. in this chapter) 

GRASP led by W. Dangelmaier, F.J. Rammig, W.H. Muller (Uni Paderborn), 
T. Kropf (Uni Tubingen) 

(see the contribution of S. Flake et al. in this chapter) 

ISILEIT led by J. Gausemeier, U. Glasser, W. Schafer (Uni Paderborn) 

KNOSSOS led by H.D. Ehrich, E. Schnieder (Uni Braunschweig) 

(see the paper of S. Einer in this chapter) 

SAW led by G. Saake, S. Conrad, D. Ziems (Uni Magdeburg) 

SFC-Check led by Y. Lakhnech, W.P. de Roever (Uni Kiel), S. Engell, 
S. Kowalewski (Uni Dortmund) 

SpeciMen led by J. Desel (Katlr. Uni Eichstatt-Ingolstadt), H.-M. Hanisch 
(Uni Halle- Wittenberg) 

(see the paper of J. Desel et al. in this chapter) 

Additionally, we are happy that a paper from an internationally reputed 
research group, authored by L.M. Kristensen and K. Jensen, Aarhus University, 
is included in this chapter. 



2 Process Languages and Methods in Computer Science 
and in Engineering 

Process description languages used by engineers and those used by computer 
scientists have many similarities. Sometimes they share common sources, e.g. 
automata or Petri nets, that were developed long before software specification 
techniques were an issue. Some languages have been taken from the other field, 
e.g. graphical languages from the UML created from software engineers for soft- 
ware engineers are adopted to the engineering field. 

The title of this introductory paper does not sufficiently indicate that most 
of the work done in this subject area deals with methods rather than only with 
languages. In other words, not the actual language is most relevant for the success 
of an apporaclr but rather the way a model given in terms of a specific language 
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is used within the development process of a dynamic system in engineering or 
computer science. 

Engineering has a remarkable and successful history in methods for system 
development processes. Moreover, there are various engineering disciplines which 
share some common principles but which have completely different methods and 
models. This is mainly due to the different requirements within the disciplines 
(compare, e.g., architecture with electrical engineering). There seems to be a 
general agreement that this situation is satisfying in engineering. The traditional 
approaches are, however, not immediately applicable to technical systems heavily 
based on complex software. 

Conversely, there is a vivid discussion in computer science on process models 
and methods since years. However, these considerations have only led to stan- 
dards within single companies or within public administrations but there is no 
agreement on the standard practice. Many different languages were developed 
and applied in the last decades, leading to a situation where each model (each 
method, respectively) was understood by only a small number of users although 
the goal of many modelling languages was quite comparable. The rise of the 
UML with its various languages (and variants) together with associated meth- 
ods and tools was motivated by this unsatisfactory situation. Although the UML 
stems from a particular need to model software systems in a specific domain in a 
unique and understandable way, the languages of the UML are nowadays applied 
in almost every domain of computer science and even in engineering. These gen- 
eralizing approaches are not always successful because often other approaches 
are more appropriate. Moreover, the UML lacks (by purpose) precise semantics 
for their languages - or several competing semantics have been published and 
models can often be interpreted in more than one way. Although some people 
claim that the UML is a step towards necessary standards, it turns out that 
actually some of its languages constitute a step backwards compared with other 
more traditional standardized notions which are not that widely spread though. 

As modelling languages and methods cannot easily be carried over from en- 
gineering to computer science, traditional computer science methods are not 
always appropriate in the engineering field. However, the possible transfer of suc- 
cessful approaches from one discipline to the other is an important research issue 
- the vision is to participate from long experiences and to avoid errors. More- 
over, embedded systems require specifications that address both, engineering 
and software aspects. These specifications have to be developed and understood 
by practitioners from both areas. 

The aim of the subject area and hence of this chapter is to study relations, 
intersections, possible generalizations and applications of process specification 
languages and methods applying respective specifications from engineering and 
computer science. In particular, we consider the methods based on Petri nets, 
which can be viewed as a quite old “unifying modelling language” for process 
modelling with sound mathematical semantics, with a uniform graphical nota- 
tion, with existing analysis tools, and with numerous applications in engineering 
and in computer science. 
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3 Articles in This Chapter 



In this section we provide a short survey on the papers published in the chapter. 



Specification and Verification of Product Automation Systems with 
Real-Time Properties 

The GRASP project is based on a successfully applied specification language for 
production automation systems, called MFERT 2 . MFERT-models have many 
similarities with Petri nets. One of the main issues of the GRASP project was to 
specify and verify formal properties of MFERT models. This includes definition 
of a formal semantics and identification of relevant properties. The verification is 
based on efficient model checking. Moreover, for making the results immediately 
applicable for engineers, tools for graphical animation have been developed. 

The first paper of this chapter (after this introduction), Specification and 
Formal Verification of Temporal Properties of Production Automation Systems, 
authored by Stephan Flake, Wolfgang Muller, Jurgen Ruf, and Ulrich Pape con- 
centrates on temporal properties. The specification language RT-OCL is defined 
as an extension of the language OCL for the specification of constraints in the 
context of UML diagrams. 

On a more formal level, MFERT models are translated to I/O Interval Struc- 
tures, and RT-OCL-specifications are translated to expressions in a timed vari- 
ant of the temporal logic OCL, namely Clocked CTL. Fed with this, the model 
checker RAVEN returns traces of counter examples which are visualized by a 3D 
animation. 



A Formal Specification Technique of Operational Processes Applying 
Colored Petri Nets 

The author of the second contribution, Stefan Einer, is today employed by Swiss 
Federal Railways. In fact, the railway domain had been his research area be- 
fore, at the University of Braunschweig, where he was particularly active within 
the project KNOSSOS. His approach presented in the paper STOP Specifica- 
tion Technique of Operational Processes was developed in this context (and also 
shows a railway crossing example) but is apparently applicable in a more general 
setting. 

As the author writes in his abstract, STOP is a methodical specification 
and a formal technique, and a specific application of colored Petri Nets. So 
colored Petri nets serve as the underlying language for processes. The paper 
distinguishes validation of specifications and verification techniques based on 
occurrence graphs of colored Petri nets. Surprisingly, Petri nets are used in the 
paper also to describe the verification process model. 

2 Modell der Fertigung (model of manufacturing) 
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Design and Specification of a Protocol for Mobile Networks 

The next paper was written by Lars Michael Kristensen and Kurt Jensen, the 
latter being well-known for the introduction of colored Petri nets and, together 
with his research group in Aarhus, development of the CPN tools - the lead- 
ing academic Petri net tool suite. Their article Specification and Validation of 
an Edge Router Discovery Protocol for Mobile Ad-hoc Networks describes ex- 
periences from an industrial case study. Like the previous paper, colored Petri 
nets and Petri-net-based verification techniques are employed. The domain of 
the application is again in engineering, but it is completely different from the 
railway domain of the previous paper. Clearly, the authors use the CPN tools 
from Aarhus for verification. 

Besides the language and the tool, the particular application domain is spe- 
cific for this paper. Another remarkable point is that Message Sequence Charts 
have been employed in this project, too. The link between Petri nets and Mes- 
sage Sequence Charts proves that there is not necessarily competition between 
these notions. Rather the computer scientists and their tools have to adapt to 
the appropriate and known language of their users, namely the engineers. 



Synthesis of Control in Automation Systems 

The Guide to Modelling and Control with Modules of Signal Nets by Jorg Desel, 
Hans-Michael Hanisch, Gabriel Julias, Robert Lorenz, and Christian Neumair 
has two, more or less independent, parts. Since the results of the project SPEC- 
IMEN only fits well in this subject area, two different aspects of the developed 
concept are combined to one paper; Part 1 surveys the syntax and semantics 
of modular signal Petri nets whereas Part 2 provides an (informal) illustrative 
description of the automatic synthesis of control modules from a given specifi- 
cation. 

Again Petri nets are applied, but in this approach these nets are elementary, 
i.e., without colored individual tokens. Instead, the application domain of mod- 
ular automation systems with distributed plant and control modules asked for a 
modular extension of Petri nets. Since, in reality, physical entities communicate 
via signals from sensors and to actuators, respective signal arcs are added to 
Petri nets for allowing a faithful modelling of modules. This way, the advantages 
of Petri nets, namely their immediate representation of concurrency, conflicts 
and synchronization, are preserved while the engineering view of blocks commu- 
nicating by signals is also respected. An important feature of signal Petri nets 
and their modules is that the numerous analysis methods for Petri nets can still 
be applied to this extended class of Petri nets. 

The control synthesis procedure described in the second part essentially fol- 
lows the known procedure from supervisory control. The latter is, however, based 
on automata. So the (more involved) aim of the approach presented here is not 
only to start with Petri net modules but also to end up with a Petri net module 
modelling the “maximally permissive” control for a given specification of the 
output behavior of a plant. This contribution does not contain the full proofs of 
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the necessary results but rather points to the original papers containing these 
results. It demonstrates the concept in an illustrative way. 



Conceptual Models for Product and Plant Automation 

The last contribution of this chapter is a bit off-beat in the sense that Petri nets 
are not mentioned at all. Katja Fischer, Peter Gdlmer, Felix Gutbrodt, Uwe 
Katzke, and Birgit Vogel-Heuser from the project DisPA identify in Concep- 
tual Design of an Engineering Model for Product and Plant Automation deficits 
of the UML when applied in engineering. They come up with a draft for an 
object-oriented approach in the domain of automation and process control. In 
particular, UML stereotypes for control, configurations of attributes and opera- 
tions to achieve reusability and real time constraints are considered. 

Although this paper does not follow the line of the other papers in this chap- 
ter, it nicely complements the view of the other papers. For example, the previ- 
ously mentioned paper from Desel et al. refers to a black box view of modules 
in a closed loop to motivate a comprehensive and faithful modelling approach 
based on Petri nets. Hence modelling principles have been transferred from en- 
gineering to computer science, thus modifying the language accordingly. In the 
present paper, concepts from computer science are transferred to engineering, 
thus detailing or refining the box models of a closed loop. 

4 Resume 

A summarizing view at the papers of this chapter and additional work done 
within this subject area as well as in other subject areas made very clear that 
there is no best or universal process description language for software specifi- 
cation in engineering. Instead, there are numerous parameters associated to an 
application, including in particular 

— the area of engineering, 

— the particular persons involved in the development and their respective back- 
ground, 

— aspects like real-time and priority, 

— dependability and security issues, 

— availability of analysis techniques and tools, 

— the characteristics of the software and 

— the platform under consideration. 

Each setting of these parameters may lead to a different appropriate language 
and method. 

Instead of hunting for a perfect language and method, the experience from 
the research results obtained in the subject area showed that marriage between 
languages is necessary and fortunately - possible in various ways. It will rarely 
be a good idea to try to convert researchers or even practitioners from other 
areas to the own models. Instead, identifying the appropriate metlrod(s) and the 
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required features of a modelling language in an interdisciplinary field is already 
a problem that requires research. The work done in the subject area contributes 
in this direction. 

Transformation of models with comparable expressive power but different 
representations is an issue, as well as dealing with complementary models de- 
scribing different aspects of the same object. Whereas the contributions show 
that this kind of transformation and combination is possible for many examples, 
a more general setting was not obtained in this subject area but can rather be 
expected in other subject areas of the Priority Program which are concerned 
with integration aspects. 

For ending with a positive statement, the results of this subject area also 
proved that computer scientists and engineers easily find a cooperative way be- 
tween their disciplines, although they have quite different general approaches. 
Even more, looking across the respective borderlines often gives rise to new 
views, new aspects and new relations between concepts. At least, this was my 
personal experience from several project meetings on all levels where researchers 
from computer science worked together with researchers from engineering. 
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Abstract. This article describes our approach for the specification and 
verification of production automation systems with real-time properties. 
We focus on the graphical MFERT notation and RT-OCL (Real-Time 
Object Constraint Language) for the specification of state-oriented real- 
time properties. RT-OCL is an extension of the Object Constraint Lan- 
guage (OCL) that is part of the Unified Modeling Language (UML). We 
introduce the formal semantics of RT-OCL based on a formal model of 
UML Class and State Diagrams and provide a mapping to temporal log- 
ics. The applicability of our approach is demonstrated by the case study 
of a manufacturing system with automated guided vehicles. 



1 Introduction 

In early stages of development of production automation systems, system model 
behavior is most frequently analyzed by quantitative and qualitative simulation. 
However, due to the complexity of those systems, simulation can never provide 
coverage for complete verification for those systems. In recent years, formal ver- 
ification with equivalence and model checking has received a wide acceptance 
in the domain of digital circuit and communication protocol design. A model 
checker verifies a property specification for a given state-oriented model of a 
system, typically given as a Kripke Structure. The model checker returns either 
‘true’ or generates a counter example in cases when the model does not satisfy 
the property. The counter example demonstrates an execution of the model that 
leads to a situation which falsifies the property. This can be most helpful for de- 
tailed error analysis. The most remarkable advantage of model checking is that 
the task of verifying is fully automated. However, model checking has two main 
obstacles in practical application. The first one is the state explosion problem in 
dependence to the number of possible inputs. The second one is due to the spec- 
ification of properties in temporal logics, since it often turns out that designers 
and programmers are not familiar with formal methods and regard it as a task 
too cumbersome to specify and understand properties in temporal logics. 



H. Ehrig et al. (Eds.): INT 2004, LNCS 3147, pp. 206-226, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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For production automation systems, the correct time-critical behavior of re- 
quired properties is of particular interest. This is already important in early 
phases of development to avoid expensive and time-consuming changes to the 
system under development at later stages. Though classical model checking is 
mainly for the verification of cycle-accurate behavior without timing properties, 
there are a few tools like the RAVEN model checker [36] that support the for- 
mal verification of time-annotated system models and additionally provide basic 
timing analysis. 

In this article, we present the GRASP 1 approach to formal verification of 
production automation systems. The GRASP approach covers the design flow 
for the modeling and formal verification of production automation systems by 
means of the domain-specific modeling language MFERT 2 with complementary 
visualization through animation of a virtual 3D model (cf. Figure 1). MFERT 
is a methodology and graphical language for the description and analysis of 
production automation systems. For analysis, GRASP focuses on model checking 
and integrates a model checker by seamlessly embedding it into a graphical 
environment with 3D animation for virtual prototyping, in particular for the 
animation of counter examples. The main idea was that in a first step the designer 
specifies a model in a graphical specification language, namely MFERT. The 
model, i.e. , the MFERT description, is then translated into an annotated state 
machine-based formalism (i.e., I/O-Interval Structures [38]) for model checking. 
Additionally, properties are specified and translated into temporal logics (i.e., 
Clocked Computation Tree Logic, CCTL [37]) for formal verification with the 
RAVEN model checker. Once the objects in the virtual prototype are associated 
with the system model, the execution of counter examples can be observed in 
the virtual prototype animation. 

One of the main visions of the GRASP approach was to provide practical 
means to designers with programming skills to facilitate property specification. 
We investigated existing related work and developed a pattern-based approach 
in the early phases of the GRASP project (see Section 2.1 for more details). In 
a second step, we decided to integrate an extension of the Object Constraint 
Language (OCL) [42,43] with MFERT for the specification of required proper- 
ties for production automation systems. OCL was introduced as a language for 
the specification of constraints in the context of the Unified Modeling Language 
(UML) de-facto standard [29], focusing on Class Diagrams and on guards in be- 
havioral diagrams. The syntax of OCL comes in a ‘programmer-friendly’ style 
using dot-notation and operation calls as known from object-oriented languages. 
With the wide acceptance of UML, OCL has also received a considerable visibil- 
ity. However, OCL currently lacks sufficient means to specify constraints over the 



1 GRASP (GRAphical Specification and Real-Time Verification for Production Au- 
tomation Systems) is a project within the DFG Priority Programme 1064 ‘Integra- 
tion von Techniken der Softwarespezifikation ftir ingenieurwissenschaftliche Anwen- 
dungen’. 

2 MFERT is short for ‘Modcll der FERTigung’ (German for ‘Model of Manufactur- 
ing’). 
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Model Property Counter 

Specification Example 




Fig. 1 . GRASP Approach to Verification of Production Automation Systems 



temporal behavior , i.e., the evolution of state activations and state transitions as 
well as timing constraints. Since it is essential to be able to specify such timing 
constraints for time-dependent systems to guarantee correct system behavior, we 
developed an OCL extension, i.e., RT-OCL, that overcomes this limitation and 
at the same time keeps compliant with the syntax and semantics of the latest 
version of OCL, i.e., Version 2.0 [28]. 

To seamlessly integrate RT-OCL with the domain-specific language MFERT, 
we defined UML Profiles for both MFERT and RT-OCL and defined mappings to 
the formal means of I/O-Interval Structures and CCTL, respectively. CCTL was 
introduced by Ruf and Kropf in [37] for the specification of properties over I/O 
Interval Structures. CCTL formulae are composed from propositions denoting 
predicates in combination with Boolean connectives and time-annotated tempo- 
ral operators. The temporal CCTL operators build upon the common CTL oper- 
ators and are annotated by timing intervals, such as AF [a , b] , where A is a path 
quantifier (‘on all paths') and F is the temporal CTL operator (‘ eventually in the 
future’) that is further limited by the timing interval [a , b] . For further details 
of CCTL and its application for real-time model checking we refer to [35,39]. 

The remainder of this article is structured as follows. The next section dis- 
cusses related work in the domain of (real-time) property specifications. Section 
3 gives an introduction to MFERT with an example. Section 4 introduces syntax 
and semantics of our temporal OCL extension RT-OCL. Section 5 demonstrates 
the application of RT-OCL in the context of a production automation scenario 
with automated guided vehicles. Finally, Section 6 concludes the article and gives 
an outlook on future work. 



2 Related Work 

There are already several approaches that make use of graphical captures for 
model checking, e.g., with Petri Nets or StateClrarts [6,3]. Those means are used 







Specification and Formal Verification of Temporal Properties 209 



to define the system by a model. Behavioral property specification, however, is 
usually still performed by means of temporal logics formulae, mainly in Com- 
putation Tree Logic (CTL) or Linear Time Logic (LTL). The most prominent 
formal method that investigates whether a given model satisfies such property 
specifications is model checking [8]. Model checking takes a set of synchronous 
finite state machines as a model and (a set of) temporal logic formulae as the 
specification of required properties. In application, the main obstacles for model 
checking lie in the state explosion problem and in the adequate specification of 
properties by means of temporal logic formulae [33] . Several approaches to sup- 
port property specification have been developed. In the following subsections, we 
distinguish the areas of (a) pattern-based specification, (b) graphical property 
languages, and (c) temporal extensions of OCL. 



2.1 Pattern-Based Property Specification 

To support temporal logic property specification, some approaches identify 
patterns which provide the user with structured application of formulae. First 
attempts in pattern classification led to taxonomies that coarsely distinguish 
between safety and liveness properties. A detailed pattern-based classification 
is published by Dwyer et al. in [14]. That pattern system is based on the 
investigation of more than 500 examples for property specification and presents 
a semantically ordered hierarchy of property patterns. For instance, absence, 
eventual existence, and global existence of states/events are combined as 
so-called occurrence patterns. 

The idea of patterns was adopted not just to classify but also to construct 
specifications for finite state verification. For example, the Testbed Studio is a 
framework for business process modeling that provides a small set of templates 
in natural English language for verification with the SPIN model checker [26]. 
These templates are also denoted as patterns, although they refer to concrete 
specifications in contrast to the previously mentioned classification patterns. In a 
more general approach of natural language oriented specification, the PROSPER 
project aims at the specification through an English language subset [24]. 

In the early phases of the GRASP project, we developed an interactive visual 
framework that employs structured English sentences [23] as given in Figure 2. 
Compared to other pattern-based approaches, we provide a richer set of spec- 
ifications, in particular, as we additionally cover explicit timing annotations. 
In contrast to temporal logic formulae-based approaches, non-experts can more 
easily capture the final sentence in structured English than just by CTL or LTL. 
Compared to unstructured English, the available structured English fragments 
give the uneducated user a better guidance through the allowable and non- 
allowable specifications with less iterations. However, it turned out that this 
approach leads to quite long sentences and remains too cumbersome for more 
complex applications, so that we started to investigate alternative approaches. 
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Fig. 2. Specification with Structured English Sentences 



2.2 Graphical Property Specification 

Regarding property specification by visual means we can distinguish two different 
kinds of approaches. The first ones are still syntactically based on CTL or LTL 
specifications. Those frameworks provide support to visually compose segments 
of specifications, e.g., by enabling and disabling parts of specifications during the 
development process. In UPPAAL, invariants and reachability properties can be 
specified using a very limited subset of LTL formulae [27]. To create specifications 
with this approach, the user must know how to apply and to control temporal 
logic formulae. Other approaches have an abstract graphical notation, which is 
translated to temporal logic formulae before checking. Examples are Symbolic 
Timing Diagrams (STDs) [15] and Life Sequence Charts (LSCs) [10], which are 
for StateChart verifications. 



2.3 OCL-Based Property Specification 

As an alternative to the previous approaches, we investigated UML in combina- 
tion with OCL for model checking. OCL was originally developed complementary 
to UML to restrict values of (parts of) a model, e.g., attributes or associations, 
but has recently been extended towards a more general query and expression 
language [28]. Several non-commercial OCL tools are currently available that 
implement syntax and type checks, dynamic constraint validation, test automa- 
tion, and code generation of OCL constraints. An overview can be found in 
[31, 32] 3 . OCL constraints are frequently used in the UML specification docu- 
ments at the UML metamodel level (M2 layer) to define the static semantics 
of UML diagrams. Those so-called well-formedness constraints specify syntacti- 
cal restrictions on diagrammatic model elements. There are several approaches 

3 See http://www.klasse.nl/ocl and http://www.um.es/giisw/ocltools for updated 
lists of available OCL tools. 
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that either extend OCL for temporal constraints specification or introduce alter- 
native UML-basecl means to express behavioral real-time constraints for UML 
diagrams. 

Ramakrishnan et al. [30] extend the OCL syntax by additional grammar 
rules with unary and binary future-oriented temporal operators (e.g., always 
and never) to specify safety and liveness properties. Ziemann and Gogolla [45] 
introduce similar temporal operators based on a finite linear temporal logic. 
Therein, Richter’s formal object model [31] is extended to provide a formal 
definition of system state sequences. However, it is left open how system state 
sequences are exactly derived. A similar approach has been published by Conrad 
and Turowski in the area of business modeling [9] . Their approach additionally 
considers past-temporal operators; a formal semantics is not provided. 

Distefano et al. [13] define Object-Based Temporal Logic (BOTL) to facili- 
tate the specification of static and dynamic properties. BOTL is not directly an 
extension of OCL. It rather maps a subset of OCL into object-oriented CTL. 
Bradfield et al. [2] extend OCL by useful causality-based templates for dynamic 
constraints. A template consists of two clauses, i.e. , the cause and the conse- 
quence. The cause clause starts with the keyword after followed by a Boolean 
expression, while the consequence is an OCL expression prefaced by eventually, 
immediately, infinitely, etc. The templates are formally defined by a map- 
ping to observational p-calculus, a two-level temporal logic with OCL on the 
lower level. 

In the domain of real-time systems modeling, we can find mainly three ap- 
proaches for temporal constraint specification. Roubtsova et al. [34] define a UML 
Profile with stereotyped classes for dense time as well as parameterized specifi- 
cation templates for deadlines, counters, and state sequences. Each of the tem- 
plates has a structural-equivalent dense time temporal logics formula in Timed 
Computation Tree Logic (TCTL). Sendall and Strolnneier [41] introduce tim- 
ing constraints on state transitions in the context of a restricted form of UML 
protocol state machines that define the temporal ordering between operations. 
Five time-based attributes on state transitions are proposed, e.g., (absolute) 
completion time, duration time, or frequency of state transitions. Cengarle and 
Knapp [5] present OCL/RT, a temporal extension of OCL with modal operators 
always and sometime over event occurrences. They specify deadlines and time- 
outs of operations and reactions on received signals. Events are equipped with 
time stamps by introducing a metaclass Time with attribute now to refer to the 
time unit at which an event occurs. In turn, each object can access the set of 
currently queued events at each point in time. 

In contrast to the event-based temporal extensions of OCL, we focus on 
state- oriented properties due to the intended application domain of state-based 
modeling of production automation systems with MFERT. Note that it is already 
possible to refer to the states of UML State Diagrams in standard OCL, i.e., 
the operation oclInState (stateName) returns a Boolean value that indicates 
whether a given state is currently activated or not. However, OCL does not yet 
integrate the notion of State Diagram states on the language definition level, 
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i.e., the semantics of State Diagram states in the context of OCL expressions is 
not sufficiently defined so far. To overcome this deficiency, we provided a formal 
semantics for state-oriented OCL expressions for application with UML State 
Diagrams in [22]. 



3 MFERT 

Our approach is based on MFERT as the basis for modeling of production au- 
tomation systems. MFERT is a language and a methodology for the specification 
and implementation of planning and control assignments in production processes. 
MFERT is basically a universal approach which has been successfully applied in 
various projects with different industrial partners [12,11], additionally acknowl- 
edged by the German science award of logistics [40] . An MFERT model is based 
on production elements and production processes. Production elements represent 
objects whose properties are changed by processes and transformations. Prop- 
erties of production elements are described by attributes. A production element 
obtains its own identity, composed out of the description and the element’s cor- 
relative status. Using this identity, the different states during the production can 
be associated to production elements. An MFERT model is a directed bipartite 
graph of E-nodes for elements and P-nodes for processes. The graphical notation 
of an E-node is a triangle. P-nodes are represented as rectangles. Each E-node 
represents a specific state and can be seen as a container for elements in the re- 
spective state. P-nodes represent transformations on elements, performed by the 
corresponding processes. Nodes are connected by edges that describe exchange 
relations between two nodes. Edge annotations define if a predecessor is bring- 
ing, providing, or waiting for elements and processes, as well as that a successor 
is fetching, receiving, or waiting for elements. Interface edges are for connecting 
different levels of hierarchy. They additionally allow the coupling to a real pro- 
duction environment. MFERT-Elements and MFERT-Processes are in certain 
states, which are characterized by attributes. An attribute denotes a property of 
an element and assigns a value to a relation. Constructors for the definition of 
discrete time modes are available. In practice, different time models are required 
for the definition of production assignments, e.g., the provision of the source 
materials for an assembly line may take place non-recurringly at the beginning 
of a shift, while the mounted end products are transported every hour to the 
delivery store. For implementation, model nodes are equipped with functions 
and their process control is carried out by means of message exchange between 
nodes and by a so-called global manager that coordinates the computations in 
the model. 

Figure 3 gives the MFERT example of a subsystem for the production 
of engines with processing steps Milling, Drilling, and Washing. The pri- 
mary input of the example is modeled by the E-nodes RawEngines and 
RawShafts. Corresponding processes are used to supply these items into E- 
nodes EnginesSupplied and ShaftsSupplied. Input and output buffers of 
processes are modeled by the corresponding E-nodes like ItemsBef oreMill, 
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Fig. 3. MFERT Graph of the Case Study 



ItemsAfterMill etc. The transport between stations and the primary out- 
put is modeled by different transport processes like TransportingToMill and 
Transport ingToOutput. Automated guided vehicles (AGVs) transport items 
between the different production steps, where the AGV resource management is 
modeled as a separate E-node. 

The input /output behavior of P-nodes is basically defined as time-annotated 
finite state machines whose graphical presentation is not given in MFERT. For P- 
node representation, we thus developed a variant of timed UML State Diagrams 
in [17] to define the local functionality of P-nodes. 

In order to be able to give a formal semantics, we have to limit the set of 
actions and activities of standard UML State Diagrams. We only consider actions 
and activities that perform (a) requests of P-nodes to put and get elements to 
and from E-nodes, (b) transfers of production elements between MFERT nodes, 
and (c) local transformations with a duration. Due to the limited space, we give 
just a a small example and refer to [17] for more details about the graphical 
notation, the formal model, and the dynamic semantics of MFERT. 

Consider the P-node TransportingToMill and its corresponding State Dia- 
gram given in Figure 4. The diagram specifies that a transport requires an AGV 
and either an Engine or a Shaft, where the movement between stations is ex- 
pected to be executed within 20 to 50 time units. Such basic timing declarations 
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Fig. 4. P-node TransportingToMill and its State Diagram 



are based upon information gained from the actual physical alignment of the 
production system. 



4 RT-OCL 

Figure 5 gives an overview of our formalization approach in the domain of mod- 
eling production automation systems. We decomposed the whole approach into 
four different activity parts. Figure 5 also illustrates the dependencies among 
the different activities. 

First, we integrated the notational concepts of UML State Diagrams into 
the existing formal description of Class Diagrams by Richters [31]. Basically, 
the resulting so-called extended object model is based upon a set-theoretic defi- 
nition of the UML metamodel parts for Class Diagrams and State Diagrams. In 
parallel, we developed a timed variant of UML State Diagrams. Note that this 
activity is at a lower position in Figure 5 to indicate it as a more domain-specific 
task, because timing issues are a non-standard concept of UML State Diagrams, 
while the extended object model basically concerns standard UML. Integrating 
the two formal models and applying further restrictions leads to our domain- 
specific notation MFERT, which is provided as a domain-specific UML Profile 
with stereotypes, e.g., for P-nodes and E-nodes [22]. Additionally, we defined a 
mapping to the semantic domain of 1/ O-Interval Structures [17]. 

We have also defined an extension of OCL called RT-OCL that allows for 
specification of temporal state-oriented properties. For such OCL expressions, 
we provide a mapping to CCTL formulae. The semantics of the combination of 
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Fig. 5. Overview of the Formalization Approach [16] 



MFERT notation and temporal state-oriented OCL expressions is then automat- 
ically available, as the two formal target languages already have a well-defined 
formal relationship, i.e. , CCTL formulae have a well-defined semantics over ex- 
ecution runs of I/O-Interval Structures. In that context, recall that the model 
checker RAVEN is able to verify whether a model (a set of I/O-Interval Struc- 
tures) satisfies a given property (a CCTL formula) [36] . 

The reminder of this section sketches some details of the definition of RT- 
OCL and its semantics. But first, we give an introduction to standard OCL in 
the next subsection. 



4.1 OCL 

The Object Constraint Language is an integral part of UML [29, Chapter 6]. OCL 
constraints are defined over a given UML model to restrict the values of object 
properties. OCL is mainly applied to define invariants for classes and pre- and 
postcondition of operations. As OCL is a declarative expression-based language, 
evaluation of OCL expressions does not have side effects on the corresponding 
UML model. 

Each OCL expression has a type. Beyond user-defined model types (e.g., 
classes or interfaces) and predefined basic types (e.g., String, Integer, Real, 
or Boolean), OCL has a notion of object collection types, i.e., sets, ordered 
sets, sequences, and bags. Collection types are homogeneous in the sense that 
all elements of a collection have a common type. A standard library is available 
with operations to select, access, and manipulate values and objects. 
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Fig. 6. Sample Class Diagram 



Assume, for example, that we have a model with classes Machine and Buffer 
and an association between these classes (cf. Figure 6). The following invariant 
defines that each instance of class Machine has at least one associated buffer: 

context Machine 

inv: self .buffers->notEmpty() 

We briefly outline how to read this OCL constraint. The identifier follow- 
ing the context keyword specifies the class for which the constraint is defined. 
The keyword inv specifies that this is an invariant, i.e., for each object of the 
context class the following expression must evaluate to true ‘at any time’ 4 . The 
(optional) keyword self refers to the object for which the constraint is evalu- 
ated. Attributes, operations, and associations can be accessed by dot notation, 
e.g., evaluation of self .buffers results in a (possibly empty) set of instances 
of Buffer. The arrow operator indicates that a collection of objects is manipu- 
lated by one of the predefined OCL collection operations. For example, operation 
notEmptyO returns ‘true’ if the accessed set is not empty. 

Standard OCL currently lacks means to specify constraints over the dynamic 
behavior of a UML model. Constraints covering the consecutiveness of states and 
state transitions as well as time-bounded constraints cannot be defined. However, 
since those are essential to specify a correct system behavior, we have developed 
a temporal OCL extension that enables modelers to specify state-oriented real- 
time constraints [19,20]. Because the official UML 1.5 specification [29] did not 
come with an OCL metamodel, our first idea was to develop an extension of 
the OCL type metamodel that was presented by Baar and Hahnle in [1]. More 
recently, in reply to the OMG’s OCL 2.0 Request for Proposals, the extensive 
OCL 2.0 language proposal by Ivner et al. [25] became available, which addresses 
a seamless integration of OCL to relevant parts of UML. In October 2003, this 
proposal has been adopted by the OMG as the official OCL 2.0 Specification 
[28]. Based on the metamodel provided in these documents, we developed a 
more lightweight approach by defining a UML Profile for our temporal OCL 
extension [22]. The syntax and semantics of this extension are briefly described 
in the following two subsections. 

4 Note that an invariant may be violated during execution of an operation. The term 
‘at any time’ has therefore to be refined by a dynamic OCL semantics. See our 
proposal in [18]. 
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4.2 OCL Syntax Extension 

The concrete syntax of OCL 2.0 is defined by an attributed grammar in EBNF 
(Extended Backus-Naur Form) with inherited and synthesized attributes as well 
as disambiguating rules. Inherited attributes are defined for elements on the right 
hand side of production rules. Their values are derived from attributes defined 
for the left hand side of the corresponding production rule. For instance, each 
production rule has an inherited attribute env (environment) that represents the 
rule’s namespace. Synthesized attributes are used to keep results from evaluating 
the right hand sides of production rules. For instance, each production rule has 
a synthesized attribute ast (abstract syntax tree) that constitutes the formal 
mapping from the concrete to the abstract syntax. Disambiguating rules allow 
to uniquely determine a production rule in the case of syntactically ambiguous 
production rules. 

The following rule gives the main production rule for temporal expressions we 
introduced for our RT-OCL extension. The idea is to interpret a future-oriented 
temporal expression as a kind of operation call. Future temporal OCL expres- 
sions map to a new stereotype FutureTemporalExp that is a specialization of 
OperationCallExp on the abstract syntax level (i.e., the OCL metamodel). For 
temporal OCL expressions, we introduce a temporal operator to distinguish 
temporal expressions from OCL’s common dot and arrow notation for accessing 
attributes, operations, and associations. 

FutureTemporalExpCS :: = OclExpressionCS ’O’ 

simpleNameCS ’(’ argumentsCS? ’)’ 

Abstract Syntax Mapping: 

FutureTemporalExpCS . ast : FutureTemporalExp 
Synthesized Attributes: 

FutureTemporalExpCS . ast . source = OclExpressionCS . ast 

FutureTemporalExpCS . ast . arguments = argumentsCS . ast 

FutureTemporalExpCS . ast .ref erredOperation = 

OclExpressionCS . ast . type . Iookup0peration( 

simpleNameCS . ast , 
if argumentsCS->notEmpty () 

then argumentsCS . ast->collect (type) 
else Sequence!!} 
endif ) 

Inherited Attributes: 

OclExpressionCS . env = FutureTemporalExpCS . env 
argumentsCS . env = FutureTemporalExpCS . env 
Disambiguating Rules: 

— Operation name must be a (future-oriented) temporal operator. 

[1] Set { ’post ’}->includes( simpleNameCS . ast) 

— The operation signature must be valid. 

[2] not FutureTemporalExpCS . ast .ref erredOperation. oclIsUndef ined() 

Note that an operation call in the abstract syntax has a source, a referred 
operation, and operation arguments. In this case, the variable ast is re-typed 
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to FutureTemporalExp and thus inherits the features source, arguments, and 
ref erredOperation from the metatype OperationCallExp. These features get 
the evaluation results of the corresponding parts of the right-hand side of the 
production rule (cf. the section ‘Synthesized Attributes 1 above). 

Additional temporal operations can easily be introduced at a later point of 
time, as just the disambiguating rule [1] has to be modified in such cases. For 
instance, nextO can be introduced as a shortcut for post(l,l), or postO as 
shortcut for post ( 1 , ’ inf ’ ) . 



4.3 Semantics 

While the syntactic integration of the temporal OCL extension is straightfor- 
ward, the definition of the semantics needs more investigation. The OCL 2.0 
specification provides extensive semantic descriptions by both a metamodel- 
based as well as a formal mathematical approach, but unfortunately, those are 
currently neither consistent nor complete [18]. 

In the metamodel-based approach, the semantics of an OCL expression is 
given by associations between the different modeling layers Ml (user model layer) 
and M2 (metamodel layer). On the one hand, each value defined in the semantic 
domain on layer Ml is associated with a type defined in the abstract syntax on 
layer M2. On the other hand, each evaluation is associated with an expression 
on the abstract syntax. Given a snapshot of a running system, the associations 
yield to a unique value for an OCL expression, which determines the result value 
of expression evaluation. 

The second approach gives the formal semantics of OCL and is based on 
set-theory using the notion of an object model [28]. An object model is a tuple 

JH = ( CLASS, ATT , OP, ASSOC, -<, associates, roles, multiplicities ) 

with a set CLASS of classes, a set ATT of attributes, a set OP of operations, 
a set ASSOC of associations, a generalization hierarchy -< over classes, and 
functions associates, roles, and multiplicities that give for each as € ASSOC 
its dedicated classes, the classes’ role names, and multiplicities, respectively. 

The formal semantics of that object model, however, lacks descriptions of 
ordered sets, global OCL variable definitions, OCL messages, and states of UML 
State Diagrams. Especially the latter are needed for our RT-OCL semantics. 
In the remainder, we call an instance of an object model a system. A system 
changes over time, i.e., the (number of) objects, their attribute values, and other 
characteristics change during system execution. This information is stored in 
system states, i.e., a system state represents a snapshot of the running system 
that is used to evaluate OCL expressions. 

In OCL 2.0, a system state o(A4) is formally defined as a triple u( M) = 
{E C lass, E ATT , E AS soc) with a set E C lass of currently existing objects, a 
set E ATT of attribute values of the objects, and a set E assoc of currently 
established links that connect the objects. However, this information is not suf- 
ficient to evaluate OCL expressions, as system states do not comprise currently 
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activated states and messages that have been sent. We therefore have to extend 
the formal model and system states accordingly, such that the resulting extended 
object model At with 

At = ( CLASS, ATT, O P, paramKind, isQuery, SIG, 

SC, ASSOC, -<, -< S ig, associates, roles, multiplicities ) 

additionally includes 

— functions that give a parameter kind £ {in, inout, out} for each operation 
parameter, 

— functions that indicate whether an operation is a query operation without 
side-effects or not, 

— signal receptions for classes with corresponding well-formedness rules, and 

— State Diagrams and their association with classes 5 . 

The formalization of the extended object model is completed by a formal def- 
inition of state configurations 6 and an extension of the formal descriptor of a 
class. 

Furthermore, the following information has to be added to system states to 
be able to evaluate OCL expressions that make use of state-related and OCL 
message-related operations: 

— for each object, the input queue of received signals and operation calls that 
are waiting to be dispatched 7 , 

— the state configurations of all currently existing active objects, 

— the currently executed operations, and 

— for each currently executed operation, the messages sent so far. 

The resulting tuple of a system state over an extended object model At is 

u(jVf) = { AjQlaSS i ATT i LJ ASSOC 5 ^CON F , 2J curr entOp, ^currentOpParami 

AlsentM sg , A/ sen tMsgP ara rm AJi n p U tQ ueue , LJi n p U f,Q ueue p aram ) 

With those extensions, it is possible to define execution traces that capture 
all of those system changes that are relevant to evaluate OCL constraints (see 
[18] for details) . The final formal semantics for our temporal OCL expressions is 
given in [22,17]. While those articles also provide a general mapping to CCTL 
formulae, we here give some typical specification examples in the next section. 

5 Note that no specific execution semantics for State Diagrams has to be assumed 
here. 

6 UML only informally defines active state configurations. This results in some short- 
comings, e.g., it is not considered that final states can be part of state configurations. 

' As we only need to consider those events that are relevant for the evaluation of OCL 
constraints, implicit events such as completion events generated by State Diagram 
executions do not have to be considered in this context. 
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Fig. 7. Virtual 3D Model of the Holonic Manufacturing System 



5 Application 

We applied the GRASP approach to the case study of a Holonic Manufacturing 
System (HMS). The HMS case study was introduced by the IMS Initiative in 
[44]. The HMS is composed of a set of different manufacturing stations and a 
transport system as it is illustrated by the virtual 3D model in Figure 7. The 
different manufacturing stations transform items, e.g., by milling, drilling, or 
washing. Additional input and output storages are for primary system input 
and output. The flexible transport system consists of a set of automated guided 
vehicles (AGVs), i.e., autonomous vehicles that carry items between stations. 
We considered that stations have an input buffer for incoming items and that 
each AGV can take only one item at a time. 

In the following, we provide some typical time-bounded constraints that refer 
to the MFERT model given in Section 3. We here just refer to the P-node 
TransportingToMill; similar constraints can be defined for other P-nodes. To 
outline the mapping, the following also gives the corresponding temporal logic 
formula in CCTL [35] for each RT-OCL constraint. 

1. When TransportingToMill is in state Idle, we require that it gets a grant 
to put an engine into the subsequent E-node EnginesBef oreMill within the 
next 100 time units. 

context TransportingToMill 

inv: self . oclInState (TransportingToMill : :Idle) 
implies 

self Opost (1 ,100) ->f or All (p : Sequence (OclState) I 

p->includes (TransportingToMill : : Requesting) ) 



// CCTL formula: 

AG ( (TransportingToMill . state==TransportingToMill . idle) 
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-> AF [1 , 100] (Transport ingToMill . state== 

Transport ingToMill . requesting) ) 

2. A transport - once started after the acknowledgments have been received - 
has to be completed within 300 time units. 

context TransportingToMill 

inv: self . oclInState (TransportingToMill : Performing) 
implies 

self Opost (1 ,300) ->f or All (p: Sequence (OclState) I 

p->exists (s : OclState I s = TransportingToMill :: Idle) ) 



// CCTL formula: 

AG ( (TransportingToMill . state==TransportingToMill .performing) 

-> AF [1 ,300] (TransportingToMill . state == 

TransportingToMill . idle) ) 

3. The acknowledgment for an available AGV within composite state Trans- 
portingToMill : Performing must be received within 150 time units. 

context TransportingToMill 

inv: self . oclInState (TransportingToMill : Performing: :GettingAGV) 
implies 

self Opost (1 , 150) ->f or All (p: Sequence (OclState) I 
p->exists(s : OclState I 

s <> TransportingToMill : Performing :: GettingAGV) ) 



// CCTL formula: 

AG ( ( (TransportingToMill_perf orming . state== 

TransportingToMill_perf orming.gettingAGV) 

& (TransportingToMill_perf orming . activated) ) 

-> AF[1,150]( (TransportingToMill_perf orming. state== 

Transport ingToMill_perf orming . movingToLoad) 

& TransportingToMill_perf orming. activated 

) 

) 

Note here, that for technical matters, the activation of composite substate 
Performing has to be considered explicitly in the CCTL formula, as ex- 
plained in [17, Section 7.3]. 

4. To enforce the production flow, it has to be guaranteed that the mill station 
is continuously served, i.e., at each point of time, state Performing will 
eventually be entered, and at each point of time, state Idle will eventually be 
entered. (The latter condition guarantees that state Performing is eventually 
left again.) 

context TransportingToMill 

inv: self @post () ->forAll(p : Sequence (OclState) I 

p->includes (TransportingToMill : Performing) ) 
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and 

self Opost () ->f or All (p : Sequence (OclState) I 

p->includes (Transport ingToMill : : Idle) ) 



// CCTL formula: 

AG AF (TransportingToMill . state==TransportingToMill .performing) 
k 

AG AF (TransportingToMill . state==TransportingToMill . idle) 

Further examples of time-bounded state-oriented OCL constraints in the con- 
text of other UML and MFERT models can be found in [20,4,1T] . In [21], we 
additionally demonstrated that it is possible to express the property specification 
patterns of Dwyer et al. [14] . 

For formal verification of MFERT models and RT-OCL/CCTL specifica- 
tions, we apply the RAVEN model checker. In RAVEN, additional timing anal- 
ysis queries help users to extract important time bounds from formal system 
descriptions. For instance, one might be interested in the maximal number of 
time steps an item is waiting until it is processed. Other typical problems are 
minimal and maximal delay times between events, e.g., the maximal time until 
the first item leaves the process. For intuitive interpretation of counter exam- 
ples, RAVEN generates execution runs to give the example of a violating path in 
the state transitions. Additionally, we have extended RAVEN to automatically 
generate traces which trigger the animation of the virtual 3D model (cf. Fig. 7). 



6 Conclusion 

We have presented the GRASP approach for the specification and verification of 
production automation systems combining the domain-specific language MFERT 
and a temporal OCL extension, i.e., RT-OCL. For application in the context of 
model checking with the real-time model checker RAVEN, we have defined the 
semantics of RT-OCL by means of a mapping to Clocked Computational Tree 
Logic. The approach demonstrates that an OCL extension by means of a UML 
Profile towards temporal real-time constraints can be seamlessly applied on the 
M2 layer of UML, i.e., the OCL metamodel. Nevertheless, some extensions have 
to be made also on the user model level (i.e., Ml layer) in order to enable 
modelers to use our temporal OCL extensions. The presented extensions are 
based on a future-oriented temporal logic. However, current work additionally 
investigates the extension to past-oriented and additional logics. 

We have implemented an editor and simulator for MFERT as given in Fig- 
ure 8. Efficient code generation for RAVEN is currently investigated and under 
implementation. The code is generated with respect to efficient runtime in BDD 
composition and model checking considering optimized module and variable or- 
ders. The temporal OCL extensions as presented here are integrated into our 
OCL parser and type checker, which translates constraints with temporal oper- 
ations to CCTL formulae. 
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Fig. 8. MFERT Editor and Simulator 
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Abstract. The formal technique STOP is a specific application of Coloured 
Petri Nets [1], It serves as a methodical specification of operational processes in 
automation systems. Each concrete specification made by using STOP can be 
verified with regard to relative completeness and correctness. The present paper 
introduces the approach and the application domain of STOP as well as its 
technical characteristics. By discussing experiences made in application of 
STOP the theoretical introduction of STOP is additionally practically substanti- 
ated. 



1 Introduction 

STOP stands for Specification Technique of Operational Processes. It has been devel- 
oped at the Institute for Traffic Safety and Automation Engineering, which is a de- 
partment of the Technical University of Braunschweig in Germany. STOP is one con- 
tribution to the priority programme of the German research council which sets up 
priorities within this LNCS volume and which is called Integration of Software Speci- 
fication Techniques for Applications in Engineering. 

STOP is a partial result of the main challenge to develop technical systems con- 
tinuously in a formal way, which also means to use formalisms for more than soft- 
ware aspects. In order to take up this challenge a set of general methodology concepts 
called BASYSNET ([2], [3]) has been developed at the above-mentioned institute. By 
intensifying BASYSNET a framework for defining formal techniques as a specific 
application of formalisms has been introduced in [4]. STOP is an exemplary result of 
successful usage of this framework. All technical characteristics of STOP as well as 
all aspects of the previously raised motivation and used frameworks etc. has been 
published within the German PHD Thesis [5]. The present paper summarizes the 
technical part of this work in order to introduce it to a broader community. 

In detail, STOP is a formal technique for specification and analysis of operational 
processes within the field of automation systems. The specification shall show the be- 
haviour of the automation system in all cases of its operation. 

The significance of STOP is that it divides the set of scenarios, which make up an 
operational process, into concurrent processes. The idea of this wellknown principle 
of concurrency is to compress the complexity of the model as opposed to an explicit 
specification of all scenarios, but still capturing all scenarios implicitly within the 
model, so that it is possible to derive them automatically. The specific approach of 
STOP is to classify each of the concurrent processes either as a so-called essential 
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process, as a supervision process or as a safety process. This abstract view is differ- 
ent from the more obvious decomposition of a model into such concurrent processes, 
which are only classified by the physical component they belong to. The specific ap- 
proach of STOP was chosen because for capturing the operational process of a com- 
plex system the detailed modelling of components-behaviour leads to models with 
non-suitable information, which are too complex for handling them easily. 

The analysis-methods of STOP firstly allow checking the completeness of a model, 
which is here meant as proving, that each scenario derived from the model ends up in 
a specified manner. Secondly the analysis-methods allow checking the correctness, 
which means to prove, that no state of the derived scenarios is an udesired one. 

Because Petri nets are a suitable formalism for concurrent modelling they are used 
as the basis of STOP. To be exact, the formalism is CPN (Coloured Petri Nets) [1]. 
There is no reason that Petri nets must be the only formalism for putting the idea of 
STOP into service. Comparable formalisms, which support concurrency, e.g. MSC 
(Message Sequence Charts) [6], might be used as well. However, as written in [7], 
Petri nets are developed on a strong mathematical base, which leads to different basic 
analysis-methods ([8]). Therefore Petri nets are very universal and some of the more 
specific formalisms fallback on the theory of Petri nets, as e.g. MSC do in [9], 

CPN are well known and are also intuitively understandable so they would not be 
introduced here in detail. 1 Rather, in the following chapter, the application domain of 
STOP will be explained. Then in chapter 3 and 4 the technical characteristics of 
STOP separated into notations and methods will be described. Chapter 5 devotes itself 
to the practical experiences made with STOP by specifying and analysing the opera- 
tional process of the radio based railway crossing, which is known as one of the two 
case studies provided from the above mentioned priority programme and which is 
generally introduced also within this LNCS volume. Finally this paper presents the 
conclusions. 



2 Specifications of Operational Processes 

There are different possibilities for dividing automation systems. An overview of 
technologies of automation systems is given by [10]. From the technological point of 
view engineering and computer science are joining each other very tightly, which can 
be seen clearly by terms as e.g. process informatics ([11], [12]). Therefore the auto- 
mation science has to take care of complex tasks in information theory [13]. That 
leads to the neccessity to combine the engineering sciences and the computer science 
also at a theoretical level. STOP is such a combination because it supports the engi- 
neering task of abstract process design by using computer aided modelling and analy- 
sis. The following subchapters explain the named engineering task by firstly introduc- 
ing the term operational process and secondly by describing the task of specifying the 
operational process. Then the approach in formalising this specification process will 
be shown. 



1 In order to get a close description also for readers beeing not familiar with CPN essential as- 
pects of this formalism are explained by footnotes if it is needed for understanding a certain 
statement. 
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2.1 The Operational Process in Automation Systems 

One possible functional division of automation systems is to differentiate between: 1. 
process 2. command and control functions and 3. environment ([2]). The scope of 
automation systems defined by this concept is the same that is used within the present 
paper, but the process term is used differently here. The notion process within this 
paper describes not only the behaviour of the part of the system that is to be con- 
trolled and what can be called the process in a closer sense, but also the behaviour of 
the control system itself. This holistic view is sensible, because the general objective 
of the automation system integrates two different objectives. These two objectives are 
firstly the objective of the process in the closer sense, which is generally the transport 
or transformation of energy, material, or information ([14]) and secondly the objective 
of the automation which is the economy and quality of the process. To limit the scope 
of the automation system to only one of these objectives can lead to the missing of 
optimisation of the whole system. Therefore by definition a view of the whole system 
must include the holistic behaviour. This behaviour is here called the operational 
process. It terms the process in broader sense integrated within its environment and 
therefore the behaviour of the whole automation system. But merging the different 
views cannot be done without using another structuring approach, because operational 
processes are too complex to handle them trivially in a holistic way. Therefore STOP 
introduces the approach to divide the operational process into concurrent parts, which 
are either so-called essential or which are serving the supervision or the safety. This 
concept follows the objective that beside the objective of the automation system the 
operational process also has to guarantee the safety of the system and its environment 

([15]). 

2.2 Aspects of Specification of Operational Processes 

Specifying is principally an evolutionary process. Especially the non-standardised 
part of this process falls within the field of creative activity [16]. So the focus of stan- 
dardisation of the process shall be to guide and support the creative activity and not to 
replace it. Because of that it is assumed that the basis of the specification of the opera- 
tional process is a concept of the operational process that is principally sufficient for 
reaching the objective of operation. 

First of all the concept of the operational process intends target behaviour under 
ideal conditions, here called normal behaviour. Moreover with the concept it is regu- 
larly known which states of the system are generally prohibited because they are dan- 
gerous or otherwise undesired. Additionally the concept tells us which behavioural 
aspects of the operational process cannot be specified deterministically. On the one 
hand these aspects are failures, because it happens always spontaneously. On the 
other hand it can be events within the environment that can take place due to being 
out of focus of the control from the control system. This includes the operational be- 
haviour of humans within the automation system, because their handling includes lot 
of potential variations. 

Coming from the concept the first task in order to specify the operational process is 
to analyse how the normal behaviour is influenced by the nondeterministic properties 
of the system. Because of these properties states regularly become possible which are 
prohibited or miss the possibility to progress to target states. In this case the specifica- 
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tion must determine the system behaviour which prevents the prohibited states and 
which closes the gap between the dead end and the target states. Therefore alternative 
scenarios that include processes of supervision and safety supplement the straight 
lined normal scenario. At the end the specification of the operational process is a set 
of scenarios. It is closed if all possible system states in which the ongoing behaviour 
is undetermined or inadmissible can be excluded with certainty. 



2.3 Approach of Formalising the Specification 

The motivation in formalizing the specification is caused by the difficulties of the 
conventional specification process. One main direct problem is to proof conventional 
specifications to its correctness and completeness. 

Within the present paper completeness is meant as the property that in every state 
of the system that is reachable because of the specification the ongoing states are also 
defined by the specification. Correctness of the specification means here that the sys- 
tem will not come in states, which are forbidden, if it behaves in accordance to the 
specification. Therefore, in order to check the correctness, forbidden states must be 
defined, for example from a safety point of view. 

Checking out the completeness and correctness of the specification is difficult be- 
cause automation systems have a wide range of possible behaviour and therefore the 
size of information for the specification is also a wide range. This is mainly because 
the fact those deviations from the ideal behaviour of the system are appearing nonde- 
terministically. The deviations firstly lead to behavioural variations because of the di- 
rect changing of the essential process and secondly because of the changing of the su- 
pervision and safety processes which has to be specified as a result of the first 
changing. All in all, the nondeterministic deviations lead to an exponential increasing 
of the amount of possible system behaviour. 

Because of the wide range of the possible system behaviour the specification con- 
sists of a set of scenarios that cannot be easily overlooked. However, today the engi- 
neers decide about the completeness and correctness of this set mostly only by their 
experience. This weak situation would be improved if the engineers were supported in 
their specification and proving tasks by a computer aided method. 

To reach this goal it is necessary to form the process and the result of the specifica- 
tion that the completeness and correctness of the specification can be verified auto- 
matically. The approach used here in realising such ability is a step-by-step specifica- 
tion process shown in fig. 1 . 

The first step of the proposed specification process is the modelling. Firstly it 
serves the purpose to bring methodically the application knowledge into a formal 
model, which describes the operational process holistically. This model is then a first 
design of the correct and complete specification of the operational process. Moreover 
the modelling serves secondly as the specification of the model requirements. The lat- 
ter specification possibly contains requirements that originate from the application 
knowledge of the engineer like the model of the operational process does. The other 
parts of the Specification of the model requirements are related to the form of the 
model of the operational process. This part can be automatically derived for each sin- 
gle case from generic requirements valid for all models, which are created by using 
STOP. That is the main gain in using STOP because the latter requirements are also 
specific for the application but they are not needed to be known explicitly for each 
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single application by the engineer but only in general as knowledge about formal 
marks. 
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[specification is not 
validated yet] 



N 




Fig. 1 . Approach of the formal specification process 



Formal verification of the model of the operational process against the specifica- 
tion of the model requirements is a part of the second step within the specification 
process. In case of success the verification is followed by a more or less informal 
validation of the model of the operational process. The validation is a proof of the 
model against the complete concept. In difference to the verification it is not the prov- 
ing of completeness of the already specified parts of the operational process but the 
proving if all parts have been specified. 

If the present state of the model of the operational process cannot be verified or if 
the validation reveals a not completly sufficient specification this result must be inter- 
preted related to the application. Then the concept of the operational process must be 
supplemented. Followed by that the model of the operational process and the specifi- 
cation of the model requirements will be methodically supplemented as well, this 
means an iterative cycle of the specification process. 

Once the verification and validation leads to success the specification process is 
done. In this case the model of the operational process is the complete and correct 
specification of the operational process. 

The following chapters show how the presented approach of formal specification is 
realised by the formal specification technique STOP. 



3 The Notation of STOP 

The notation of STOP, i.e. the notation of a formal technique, is more than the nota- 
tion of the basically used formalism. The notation of STOP includes a specific defini- 
tion and interpretation of elements or constructions of the formalism CPN from a 
view of a general system theory ([11], [17], [18]). Therefore concepts of system the- 
ory can be identified which are typical of STOP as well as the familiar formalism. 

The next subchapter gives an overview about the concepts of system theory used 
by STOP. In the first place these concepts are described independently from the for- 
malism. Then, within the following subchapter, it is shown, how the used concepts of 
system theory are realised as modelling concepts by the utilisation of CPN. The ge- 
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neric patterns used to explain the modelling concepts are called design patterns within 
the present paper. 



3.1 Concepts of System Theory Used by STOP 

The basic concepts of system theory used by STOP are shown in fig. 2. Altogether the 
potential behaviour of a system is the focus of attention. The further approach in 
structuring this behaviour is to construct it by combination of concurrent processes. 
For that purpose two categories of processes are distinguished: 1. sequential proc- 
esses and 2. communication processes. These processes can be decomposed into ele- 
ments, which are describing either process states or process state transitions. 

The further decomposition of these concepts is important from the view of causal- 
ity. Process states can be separated into activities on the one hand and pure states on 
the other hand. Activities are focussing continuous subprocesses onto a discrete ab- 
straction level, but pure states are static. 

Process state transitions are distinguished between events and reactions. Further- 
more events are separated into endogenous and exogenous events. Endogenous events 
occur within the system, while exogenous events are related to the system environ- 
ment. 

Process elements can be further specialised. The sort of specialisation depends on 
the process category to which the process element belongs. It is exemplary shown in 
fig. 2 but shall not be discussed here in more detail. 

Last bnt not least, uncoupled from the previously described aspects of structure, 
decomposition and causality, the temporal concepts shall be added. The basic state- 
ment concerning this is that process states have duration, while process state transi- 
tions occur in an instantaneous moment. 



3.2 Basic Desing Patterns 

Two kinds of design patterns have been developed during the development of STOP. 
Firstly such design patterns, which define the basic approach in actually putting in 
service the concepts of system theory. Secondly there are such design patterns, which 
serve the purpose of optimising the basic design patterns in order to reach goal- 
directed model behaviour. Concretely speaking these design patterns serves the limi- 
tation of the state space of the model and the control of conflicts between subscenar- 
ios. In order to point out the main aspects of STOP the following paragraphs describe 
only the basics of the firstly mentioned design patterns. They are structured by the as- 
pects: structure (including decomposition), causality and temporality, because these 
are suitable aspects in differentiating special features of Petri nets. 

3.2.1 Model - Structure Composed by Coupled Processes. Each specification built 
by using STOP is described through one single Petri net. As previously described by 
explaining the concepts of system theory such a net consists of sequential processes 
and communication processes. Fig. 3 shows an example design pattern, in which two 
sequential processes are connected by one communication process. 
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Fig. 2. Concepts of system theory used by STOP 



The sequential processes are constructed as an example, i.e. their inner structure 
can be different. The essential point is that every sequential process is a state ma- 
chine, i.e. there is never a branching at a transition. 2 A sequential process has one 
starting place and at least one ending place. All elements of the sequential process are 
connected in a unique running direction. The starting place of a sequential process is 
provided with the initial marking of the process, which is a local part of the global ini- 
tialisation marking. 

Aside from the communication processes there is another kind of coupling sequen- 
tial processes named feedbackfree statecoupling. It is also shown in fig 3. The cou- 
pling element between the sequential processes of such coupling is a so-called status 
place. The token providing the status place is carrying the information of the present 
status of a certain sequential process (here sequential process 1). By connecting the 
status place to other sequential processes (here sequential process 2) the behaviour of 
the latter processes can be conditioned by the first one. 



3.2.2 Causal Meaning of Model Elements. A transition belongs to one sequential 
process either exclusively or to one or more communication processes additionally 
(fig. 4). In each case a transition has exactly one pre-place and exactly one post-place 
of the sequential process it belongs to. Further more it has at most one pre-place of a 
communication process and maybe one or more post-places of communication pro 
cesses, which then each of them must belong to different communication processes. 



2 A transition is one from the two disjunctive kinds of nodes of a Petri Net. Considering CPN 
the other one is called place. Places, mostly visualised as circles or ellipses, describe poten- 
tial local states, which are reached, if the places are provided with a certain set of tokens. 
Transitions are able to change the marking of the places which surrounding them, i.e. they 
describe potential transitions from one local state of the Petri Net to one other. Transitions 
are mostly visualised by rectangles. 
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Fig. 3. Basic design pattern of an example model-structure 



Within the above-described concept of system theory used by STOP on the one 
hand process states have already been distinguished between activities and states and 
on the other hand process state transitions have been distinguished between events 
and reactions. These differentiations determine the causality of the model of the op- 
erational process and leads to the corresponding interpretation of the meaning of 
CPN-elements, i.e. places on the one hand and transitions on the other hand. As well 
as events reactions are described by transitions. Activities and states are described by 
places. In more detail each transition depicts exactly one event and possibly one or 
more reactions relating to the other processes that are containing the transition. 

3.2.3 Temporal Meaning of Model Elements. The duration of a process state and 
the time of a process state transition are generally not modelled absolutely, but they 
are fixed by two aspects: Firstly by the temporal aspects of some concrete model 
elements, which are modelled as a part of the model structure and secondly by the 
concrete model dynamics. The latter one is not determined by some single elements, 
but by all of them and by the initialisation marking of the Petri net. 

Within the present subchapter the temporal aspects described by the structure of 
the model is been shown. Events and therefore also reactions of exogenous events 
have no temporal marks of their own. Their occurring time is determined by the ele- 
ments surrounding them. Endogenous events are determined by the duration of that 
one process pre-state, which is an activity. Analogously the occurring time of exoge- 
nous events is determined by the duration of their single process pre-state. 

The temporal marks of activities are shown in fig. 5. Because of the attributing of 
the input-arc of the place describing an activity the time stamp of that token which 
starts the activity gets a value that differs from the starting time of the activity by as 
much as the activity lasts. So this value, which is the number within the attribution of 
the input-arc, describes the duration of the activity (fig. 5(a)). 
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Fig. 6. Temporal marks of reactions on communication events 

Using STOP it can be also necessary to model the duration of an activity as unde- 
fined. Therefore an additional transition is connected to the activity. This Transition 
describes neither an event nor a reaction, but is called remainity (fig. 5(b)). By firing 3 
it the remainity increments the time stamp of that token serving that place which de- 
scribes the activity. Therefore the duration of the activity can be extended dynami- 
cally. 

Using the shown design patterns in fig. 5 leads formally to the above mentioned 
fact that an endogenous event is determined by the duration of its pre-activity because 
if the activity is actually running, i.e. the place is served by a token, the only condition 
for enabling the firing of the following transition which describes the following en- 
dogenous event is that the global model time increases to the time stamp of the token 
which serves the activity-place. 4 However the design patterns in fig. 5 are only valid, 
if the endogenous event is part of a sequential process. If the endogenous event is part 
of a communication process the statements relating to fig. 5 are still true but they have 
to be extended (fig. 6). In such case the endogenous event as part of a communication 
process is causally connected to a reaction on this event, which is described by the 
same transition and which is part of a sequential process. This model concept shall be 
shortly called reaction on a communication event. 

In the centre of the temporal modelling of a reaction on a communication event 
stands a guard 5 . Fig. 6 presents the reaction on a communication event at the firing 
time of the corresponding transition together with certain characteristics of the tokens 
of the pre-places at the same time. The firing time of the transition is determined by 
the activity of the communication process. Therefore the place that represents this ac- 
tivity is served by a token with a time stamp equal to the firing time (t K ). In this situa- 
tion the process-pre-state of the reaction must than be served by a token whose time 
stamp is equal or lower than the one described before. Thus this time stamp does not 



3 Firing of a transition names the actual changing of tokens by a transition in a running Petri 
Net. 

4 In theory of CPN the global model time is incremented if no transitions is enabled to fire at 
the present global model time 

5 A guard is an additional firing condition of a transition. 
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prevent the firing of the transition and above all it is not a contribution to the trigger- 
ing of the firing at any time. Otherwise the transition would lose its role as a reaction 
on side of the sequential process and act as an event. The aforesaid guard ([t K •tj) 
prevents such behaviour in any case. 



4 Methodology of STOP 

The methodology of STOP is fixed by a process-model that combines elementary 
methods. Within the present paper firstly the elementary methods will be introduced 
separated as methods of modelling and methods of proving. Secondly the process- 
model will be sketched. All methods are discussed in general, because in detail they 
are more related to implementation of STOP than to scientific knowledge. 



4.1 Methods of Modelling 

STOP comprises the following methods of modelling: 1. modelling of scenarios, 2. 
modelling of restrictions and 3. modelling of potential deviations. 

The modelling of scenarios serves the systematical transformation of the scenario 
knowledge into the Petri net model that bases on concurrent processes. This method is 
mostly made of a set of transformation rules but it also includes the automatic con- 
figuration of some temporal aspects of the Petri net model and includes therefore also 
analytical parts. Considering the modelling of scenarios, not only the concepts of sys- 
tem theory but also the domain specific basis of STOP is important to be looked at. It 
says that each sequential process within the model is either a so-called essential proc- 
ess or a supervision or a safety process. Models built by using STOP are therefore ab- 
stract objects, which include processes that do not need to be structurally equal to 
physical processes. 

Also the modelling of restrictions serves the transformation of application knowl- 
edge into the Petri net model. But in contrast to the modelling of scenarios this 
method is not focused to sequential process but to certain functional requirements, 
which necessity will be revealed by the model proving. 

The modelling of potential deviations exists because STOP intends to increase the 
scope of a model stepwise. This is to be done by supplementing a present model by 
variation of some local behaviour aspects, which is supported by the named method. 
The effects of these variations then will be proved analytically by one certain method 
of proving, as described in the following subchapter. 



4.2 Methods of Proving 

Model Proving comprises two methods of verification that have been already men- 
tioned in chapter 2.3. On the one hand the proving of admissibility of each global 
state of the model, which is termed by correctness within the present paper, and on 
the other hand the proving of a correct termination of the model-behaviour, which is 
herein termed completeness. 
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Specification is initiated 




Both methods of verification prove global effects on local changes of a model. The 
proofs are based on analysis of the occurrence graph 6 of the Petri net model. 

For proving the correctness, permitted global states must be specified beforehand. 
Against which the criteria of verifying the relative completeness can be derived from 
the form of the model. Like this a model would be discovered as incomplete. For ex- 
ample if the guard that describes the temporal condition of a transition, which again 
describes a reaction in application, prevents the firing of the transition in certain pos- 
sible running sequences of the model. This reveals that the specified reaction, which 



6 The occurrence-graph of a petri net is the transformation of the potential behaviour of the 
petri net into a static view. The initialisation marking and each possible global marking of the 
Petri Net, which can be reached from the initialisation marking by any sequences of transi- 
tion firing is a so-called global-state and is in each single case represented by one node in the 
occurrence-graph. The orientated connections from one node to another in the occurrence 
graph then show the possible changes of one global-state into some other by firing in each 
case a certain transition, whose identity is related to the corresponding connection. 
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is represented by the transition, cannot occur in each case when the pre-places of the 
transition have been served by tokens. That means that an alternative reaction to the 
first one also has to be specified and has been missed until now. 

Beside the verification the methodology of STOP also supports validation. How- 
ever the validation is not really formal but is supported by the formal representation 
of the model. The validation also serves the completeness of the model. Related to 
this aspect, as mentioned in chapter 2.3, the difference between verification and vali- 
dation is here that by validation the model is proved to aspects which completely has 
not been modelled up to now, whereas the verification proof the completeness of al- 
ready modelled aspects. 



4.3 The Process-Model of STOP 

Fig. 7 shows the process-model of STOP in the top-level view. It is a specialisation of 
the process-model in fig. 1, which is describing the approach of the formal specifica- 
tion process. In this view each method of modelling of STOP can be found explicitly, 
while the methods of proving are only shown by their differentiation in verification 
and validation. 




Provisional Model of the Provisional Model of the 

Operational Process is partly Operational Process is 
falsified verified 



Fig. 8. The verification-process-model of STOP 



Therefore fig. 8 shows a refinement of the verification-process and fig. 9 is detail- 
ing the validation-process. Both pictures are self-explanatory related to the question 
of which method is used when. Why the methods are used in that order will not be 
discussed in more detail here, because it depends much more on technical aspects 
than on scientific effort. 
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Fig. 9. The validation-process-model of STOP 



5 Experiences in Application of STOP 

STOP has been developed inductively by modelling of the case study radio based 
railway crossing, which has been generally introduced separately within the present 
LNCS volume. The here used CPN tool is DesignCPN, Version 4.0 ([19]). 

However within the present paper we will not explain the experience of developing 
STOP but the application of STOP as a fully developed method. Therefore after fin- 
ishing STOP for the time being the named case study has also been used for docu- 
menting an example application of STOP. It will be introduced within the present 
chapter. 

The first step of the application is the modelling of the normal operational process 
of passing the level crossing. Using the scenario modelling method has done this. As 
this method was not presented in detail, here also the explanation of its application 
shall only be mentioned. But in order to convey a practical impression of the notation 
of STOP, which is much more the focus of the present paper, the result of the first 
modelling step is been shown in fig. 10. 

Four concurrent sequential processes can be seen within the model. Half of them 
are related to the train and half related to the level crossing. The train specific sequen- 
tial processes are on the one hand an essential process that is called train movement 
and on the other hand a supervision-process. The processes related to the level cross- 
ing cover one supervision- and one safety-process, which are named Ic-supervision 
and Ic-safety. The reason for the difference between the process categories of the train 
and the level crossing is that the train passes the railway crossing unhindered within 
the normal operational process, i.e. without using safety functions, while otherwise 
the level crossing has no other essential functionality as the saving of the train by it- 
self. By using the communication processes the concrete model dynamics, i.e. the or- 
der of events and reactions are coordinated. 




Train Movement Train Supervision LC-Supervision LC-Safety 

transmitting of turn- 
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Fig. 10. Model of the normal operational process of passing the railway crossing 



off state 




242 



S. Einer 




Fig. 11. Occurrence graph of the normal train passage through the railway-crossing model 

Fig. 1 1 presents the occurrence graph of the model of the normal operational proc- 
ess. Because the normal railway crossing passage is described by one single scenario 
the structure of the corresponding occurrence graph should be a sequence. In fact it is 
only nearly a sequence because CPN as interleaving-models serve no global state 
transition by firing two transitions at once. But the event train passes turn-on location 
causes two communication processes ending in two reactions that occur simultane- 
ously. This leads onto the level of formalism to two different paths of firing order 
within the occurrence graph, but on application level it is still interpreted a sequence. 

After using the methods of proving for verification and validation the model of 
normal behaviour has been firstly extended. It was changed that way that the train can 
change its speed at any times because this corresponds to real potential behaviour. 
The extension of the model has been done by adding remainities to each activity 
within the Train Movement Process (fig. 12 7 ). 

Considering the extension of its possible behaviour the system can reach the for- 
bidden state that the train is moving within the area of danger while the level crossing 
is not at safe. This can be found by trying to verify that the model behaviour never 
reach a global state where the place Ic at safe is not served by a token while the place 



7 Grey colored parts have been modelled before. 
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Train Movement 



® 




®+1 



Fig. 12. Modelling of the potential temporal deviations in train movement 



Train Movement 




Train Supervision 




Fig. 13. Modelling of the restriction related to the train entry 



train is moving within the area of danger is. This verification failed for the moment, 
so a further extension of the model, i.e. an extension of the specification, must have 
been done by modelling a restriction. This restriction describes the functional re- 
quirement that the train is to be hindered in running into the area of danger if the level 
crossing is not at safe or the other way round that the supervision of the train must be 
released before the train is running into the area of danger in every case. This restric- 
tion is modelled by a feedbackfree status coupling as shown in fig. 13. 
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Fig. 14 shows the occurrence graph of the Petri net model after modelling the re- 
striction. Its character is still being sequential, but some branches can be seen which 
partly join again but which can also lead to different dead ends. This is not fully inter- 
pretable onto application level because it originates from different concepts of STOP 
like the herein introduced remainity as well as the just mentioned concept of limiting 
the state space. All in all, by using STOP it is not useful to analyse occurrence graphs 
by its shapes visually, but the evident increasing of possible paths through the occur- 
rence graph is comparable to the increasing of the potential behaviour of the system. 
One benefit of STOP is that this amount of potential behaviour must not be specified 
explicitly, i.e. that the extension of the model is not as large as the increasing of the 
occurrence graph. 

The next modelling step was to consider the potential temporal delay in transmit- 
ting the turn-on message. Putting it in use is not really different from what we have 
seen before so that it is not presented here. However the result is different because the 
verification revealed that the reaction of the lc-supervision-process reports the status 
“at safe ” cannot be sent in every case any longer, i.e. the corresponding transition is 
no longer able to fire in every running sequence of the model. Therefore a further 
scenario, called status unsafe has been specified and was integrated into the model. 
The integrated model could be verified then. 

Further extension of the model which necessity can be revealed by further valida- 
tion has not be done until now, because the presented steps in modelling and proving 
covers the whole spectrum of STOP and reaches the goal of approving the soundness 
of this formal technique in principle. However, the state space of the specified opera- 
tional process was grown from 28 states of the normal train passage- model to more 
than 800 states after adding the described changes, so that maybe methods in more ef- 
ficient computing must be applied to make STOP applicable in real industrial usage. 



6 Conclusions 

Within the present paper the term operational process has been introduced as an im- 
portant subject in the development of automation systems. It was discussed especially 
in relation to problems with the specification of such operational processes. The main 
problem is the huge amount of scenarios which must be specified for describing the 
complete operational system behaviour and which is not possible to be checked 
against completeness and correctness manually. In order to solve these problems an 
approach of formalising the procedures and results in specifying operational processes 
has been presented. 

Afterwards it was shown how the named approach was put into use by a formal 
technique called STOP, which has been developed especially for fitting this purpose. 
The notation as well as the methods of STOP has been described by their main tech- 
nical characteristics. 

The definition of the notation of STOP has been presented by design patterns, 
which create a relation between certain concepts of system theory and the used for- 
malism Coloured Petri Nets (CPN). The methods of STOP, including methods of 
modelling as well as methods of verification and validation, has been introduced by 
explaining their intention and their composing into process models. 
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At least the practical experiences of using STOP were presented by specifying 
some parts of the operational process of the case study radio based railway crossing. 

The significance of STOP is that it divides the set of scenarios, which make up an 
operational process into abstract concurrent processes classified as so-called essential 
processes and supervision as well as safety processes. Following this approach STOP 
allows that the amount of operational behaviour of a automation system must not be 
specified total explicitly but can be partly derived analytically, i.e. that the number of 
elements of the specification model is much lower than the number of elements of its 
occurrence graph which is an indicator for the size of the explicit specification. Also 
certain application specific requirements can be derived automatically from the form 
of the model which is a benefit in automating the development process because the 
requirements are not needed to be known explicitly for each single application by the 
engineer but only in general as knowledge about formal marks. 

All in all STOP has been introduced as an approach in formal specification and analy- 
sis of operational processes in automation systems. It supports the idea of concurrency 
and proposes to classify the concurrent processes in so-called essential , supen’ison or 
safety processes. So STOP reaches the goal to compress the complexity of the model 
as opposed to an explicit specification of all scenarios. However, even if the state 
space of an operational process is derived automatically, it is still too complex to han- 
dle it for industrial usage. The further development of STOP must especially deal 
with this problem. 
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Abstract. We present an industrial project at Ericsson Telebit A/S 
where Coloured Petri Nets (CP-nets or CPNs) have been used for the 
design and specification of an edge router discovery protocol for mobile 
ad-hoc networks. The Edge Router Discovery Protocol (ERDP) supports 
an edge router in a stationary core network in assigning network address 
prefixes to gateways in mobile ad-hoc networks. This paper focuses on 
how CP-nets and the CPN computer tools have been applied in the 
development of ERDP. A CPN model has been constructed that consti- 
tutes a formal executable specification of ERDP. Simulation and mes- 
sage sequence charts were used for initial investigations of the protocol’s 
behaviour. Then state space analysis was applied to conduct a formal 
verification of the key properties of ERDP. Both the modelling, simu- 
lation, and subsequent state space analysis helped in identifying several 
omissions and errors in the design, demonstrating the benefits of using 
formal modelling and analysis in a protocol design process. 



1 Introduction 

The specification and development of communication protocols is a complex 
task. One of the reasons is that protocols consist of a number of independent 
concurrent protocol entities that may proceed in many different ways depending 
on when, e.g., packets are lost, timers expire, and processes are scheduled. The 
complex behaviour makes the design of correct protocols a challenging task. 

The specification of communication protocols is, in many cases, based on 
natural language descriptions. One example of this is the Request for Comments 
(RFC) documents published by the Internet Engineering Task Force (IETF) [17]. 
Natural language specifications of protocols have several weaknesses. Firstly, 
they are inherently ambiguous making it difficult to achieve inter-operability 
between independent implementations. Secondly, they are often incomplete in 
the sense that the behaviour of the protocol is not completely described for all 
cases. This has motivated the use of formal description techniques [3] for the 
specification and validation of protocols. 

An advantage of many formal description techniques is that they are based 
on the construction of executable models that make it possible to observe and 
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experiment with the behaviour of the protocol prior to implementation using, 
e.g., simulation. This typically leads to complete specifications since the model 
will not be fully operational until all parts of the protocol have been specified. 
Another advantage of formal modelling languages is that they support abstrac- 
tions, making it possible to specify the operation of the protocol without being 
concerned with irrelevant implementation details. Furthermore, the use of formal 
description techniques results in models that are amenable to verification using, 
e.g., state space methods where the basic idea is to compute all reachable states 
and state changes of the protocol and represent these as a directed graph. State 
space methods make it possible to automatically (i.e., algorithmically) check 
whether a protocol has the desired set of properties. In addition, state space 
methods have the advantage that counter examples (error-traces) can be auto- 
matically synthesised if the protocol does not satisfy a given property. Other 
examples of verification techniques for Petri nets [25, 10] includes structural and 
invariant methods [8,26], and partial-order and unfolding methods [9,13]. 

We present a case study from a joint research project [20] between the 
Coloured Petri Nets Group [6] at University of Aarhus and Ericsson Telebit 
A/S [12]. The research project applies formal description techniques in the form 
of Coloured Petri Nets (CP-nets or CPNs) [18,21] and the supporting CPN com- 
puter tools [5,11] in the development of Internet Protocol Version 6 (IPv6) [15] 
based protocols for ad-hoc networking [23] . An ad-hoc network is a collection of 
mobile nodes, such as laptops, personal digital assistants, and mobile phones, ca- 
pable of establishing a communication infrastructure for their common use. Ad- 
hoc networking differs from conventional networks in that the nodes in the ad-hoc 
network operate in a fully self-configuring and distributed manner, without any 
preexisting communication infrastructure such as base stations and routers. Net- 
work layer and routing protocols for ad-hoc networking are under development 
by the IETF Mobile Ad-hoc Networks working group [14]. 

The CPN modelling language combines Petri nets and programming lan- 
guages. Petri nets [25, 10] provide the foundation of the graphical notation and 
the semantical foundation for modelling concurrency, synchronisation, and com- 
munication in systems. The functional programming language Standard ML [27] 
provides the primitives for compactly modelling the sequential aspects of sys- 
tems (such as data manipulation) and for creating compact and parameterisable 
models. State space methods are the main verification techniques for CP-nets. 
The CPN modelling language is supported by two computer tools: CPN Tools [51 
and Design/CP N [11], 

This paper shows how CP-nets and the CPN computer tools have been 
used and integrated in the development of the Edge Router Discovery Protocol 
(ERDP) . ERDP is a protocol for connecting gateways in mobile ad-hoc networks 
to edge routers in stationary core networks. ERDP allows gateway nodes to dis- 
cover and create an attachment to the core network, and it allows edge routers to 
configure gateways with a globally routeable IPv6 address prefix. This address 
prefix can, in turn, be used by the gateway to configure global IPv6 unicast 
addresses for the mobile nodes in the ad-hoc network. CP-nets have previously 
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been applied in a number of industrial projects for the specification and analysis 
of protocols and systems [16]. 

The paper is organised as follows. Section 2 gives a brief introduction to 
ERDP explaining the basic operation of the protocol. Section 3 presents selected 
parts of the CPN model specifying ERDP, and Sect. 4 shows how the protocol 
was analysed and verified using state spaces. Finally, in Sect. 5 we sum up the 
conclusions. The reader is assumed to be familiar with the basic ideas of Petri 
nets, high-level Petri nets, and state space methods. The paper [21] gives an 
introduction to CP-nets sufficient to understand the results presented in this 
paper. The reader is referred to [18] for a complete introduction to CP-nets, 
their analysis methods, and applications. 



2 The Edge Router Discovery Protocol 

This section gives a brief introduction to the Edge Router Discovery Protocol 
(ERDP) . The aim is not to give a complete description of ERDP, but to provide 
sufficient information to understand the CPN model and the state space analysis 
results presented in the later sections. 

Figure 1 shows the IPv6-based network architecture considered in the project. 
The network architecture consists of an IPv6 stationary core network connecting 
a number of mobile ad-hoc networks on the edge of the core network. The project 
focuses on IP routing in this hybrid network architecture. A number of edge 
routers reside on the edge of the core network, and an ad-hoc network may 
contain one or more nodes capable of acting as gateways for communication with 
nodes outside the ad-hoc network. The edge routers and the gateways handle 
the connection between the core network and the ad-hoc networks, and an edge 
router may serve multiple ad-hoc networks. The core network is a classical wired 
IP network with stationary nodes, whereas wireless communication is used for 
communication between the mobile nodes in the ad-hoc networks. The edge 
routers and the gateways are also connected via wireless links that may be 
different from the wireless link technology used internally in the ad-hoc networks. 

The network architecture also encompasses mobility. The nodes in the in- 
dividual ad-hoc networks may move within the ad-hoc network or between the 
ad-hoc networks. It is also possible for an entire ad-hoc network, including its 




Fig. 1 . IPv6-based Networking Architecture. 
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gateways to move from one edge router to another edge router, and possibly be 
within reach of several edge routers simultaneously. 

ERDP is used between the gateways in the ad-hoc networks and the edge 
routers in the core network. ERDP supports gateways in discovering edge routers 
and supports edge routers in configuring gateways with a globally routeable 
IPv6 address prefix. This address prefix can then be used to configure global 
IPv6 unicast addresses for mobile nodes in the ad-hoc networks. This has the 
effect that all nodes in a given ad-hoc network will have addresses based on the 
same IPv6 address prefix, and entries in the routing tables in the core network 
can therefore be based on address prefixes rather than having to contain the 
individual addresses of the ad-hoc network nodes. This ensures that the network 
architecture scales with respect to the number of entries in the routing tables. 
When an ad-hoc network moves from one edge router to another edge router, it 
must be configured with a new topologically correct IPv6 address prefix for the 
same scalability reasons. Gateway discovery and selection by nodes in the ad-hoc 
networks are handled by protocols executed internally in the ad-hoc networks 
and is outside the scope of ERDP. 

ERDP is based on extending the Neighbour Discovery Protocol (NDP) [22] 
which is part of the IPv6 protocol suite. The intended use of NDP is for hosts 
to discover neighbouring nodes and routers on a local area network, and con- 
duct address configuration. In the IPv6-based networking architecture in Fig. 1, 
gateways acts as hosts and edge routers acts as routers from the point of view 
of NDP. Standard NDP can however not be used for configuration of gateways 
with address prefixes in the above network architecture since it must be ensured 
that a given address prefix is only assigned to a single gateway. This is required 
to ensure that routing of packets from edge routers to gateways is well-defined 
in case an ad-hoc network splits into two ad-hoc networks each with their own 
gateway. 

Figure 2 shows the basic way that an edge router configures a gateway with 
an address prefix using ERDP. The message sequence chart was generated auto- 
matically from the CPN model to be presented in Sect. 3. The column labelled 
GWBuffer represents packet buffers between the gateway protocol entity and 
the underlying protocol layers. Similarly, the ERBuffer column represents packet 
buffers in the edge router. 

An edge router periodically multi-casts unsolicited router advertisements 
(RAs) to announce its presence to any gateways that may be within reach of 
the edge router. When an unsolicited RA is received by a gateway, it will reply 
with its list of currently assigned address prefixes in a unicast router solicitation 
(RS). In this example, the gateway has no current prefixes and hence it sends 
an RS with no prefixes (indicated by the empty list [ ]). When the edge router 
receives the RS it will consult its lists of available prefixes and in this case select 
a new address prefix (PI) to be assigned to the gateway. This newly assigned 
prefix will then be sent back to the gateway in a unicast RA. When the unicast 
RA containing the prefix is received by the gateway, it will update its lists of 
currently assigned prefixes to contain the new prefix PI. Prefixes assigned to 




252 



L.M. Kristensen and K. Jensen 



Gateway 



Updating : PI 



GWBuffer 



Unsolicited RA 



Solicited RAfPII 



ERBuffer 



EdgeRouter 



Unsolicited RA 



RS f 



Solicited RAfPII 



Unsolicited RA 



RSf 



Solicited RA [PI] 
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Fig. 2. Message sequence chart for basic prefix configuration with ERDP. 



gateways have a limited lifetime, and hence either will expire or will have to be 
refreshed by the edge router. 

CP-nets were integrated in the design and specification of ERDP by de- 
veloping a CPN model of ERDP together with a conventional natural language 
specification. In the following sections we will refer to the natural language spec- 
ification of ERDP as the ERDP specification. 



3 CPN Modelling 



Figure 3 shows the hierarchy page of the CPN model providing an overview of the 
pages (modules) constituting the CPN model. Each node in Figure 3 represents a 
page in the CPN model, and is labelled with a page name and a page number. As 
an example, the page node at the top left is named ERDP and has page number 
1. Page ERDP is the most abstract page in the CPN model. An arc between 
two nodes indicates that the destination page is a subpage (submodule) of the 
source page. The arc label(s) specifies the name of the substitution transition(s) 
representing the corresponding subpage at the source page. 

The CPN model consists of three main parts. Page Gateway and its four sub- 
pages model the operation of the gateway. Page EdgeRouter and its five subpages 
model the operation of the edge router. Page GW_ER_Link models the wireless 
communication link between the gateway and the edge router. We consider a 
system consisting of one gateway and one edge router as this is sufficient for 
specifying the protocol itself, and for investigating its basic operation. Valida- 
tion of ERDP in an environment with multiple gateways and edge routers is 
beyond the scope of this paper. 

Figure 4 depicts page EDRP. It corresponds to the ERDP page node in Fig. 3. 
The substitution transition Gateway represents the gateway, and the substitu- 
tion transition Edge Router represents the edge router. The communication link 
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Fig. 3. Hierarchy page - overview of CPN model. 




Fig. 4. The ERDP page - top level page in the CPN model. 



between the edge router and the gateway is represented by the substitution tran- 
sition GW_ER_LINK. The four places GWIn, GWOut, ERIn, and EROut model 
packet buffers between the link layer and the gateway and edge router. Both 
the edge router (ER) and the gateway (GW) have an incoming and an outgoing 
packet buffer. 
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3.1 Modelling Packets 

All four places in Fig. 4 have the colour set (type) IPv6Packet used to model 
the IPv6 packets exchanged between edge routers and gateways. Since ERDP 
is based on the IPv6 Neighbour Discovery Protocol (NDP) [22], the packets are 
carried as Internet Control Message Protocol (ICMP) [4] packets. The definitions 
of colour sets for NDP, ICMP, and IPv6 packets are given in Fig. 5 and have 
been derived from RFC 2460 [7] specifying IPv6 and RFC 2461 [22] defining 
NDP. IPv6 addresses and address prefixes are modelled as strings. This makes 
it possible to use both mnemonic names and standard hexadecimal notation for 
IPv6 addresses in the CPN model. Protocol fields that do not affect the operation 
of ERDP have been defined using the colour set NOTMOD containing the single 
dummy value notmod. These fields could alternatively have been omitted, but for 
the later implementation of ERDP it was considered important that the tokens in 
the CPN model have the same set of fields as the packets in the implementation. 
The colour sets Ulnt8, Bit4, and Bit8 (not shown) used for bit fields in the packets 
are all defined as integers, as we are not concerned with the specific layout of 
packets and the domain of the bit fields, but only their semantics. 



3.2 Modelling the Edge Router 

Figure 6 shows the page EdgeRouter modelling the edge router. The port, places 
ERIn and EROut are assigned to the similarly named socket places on page ERDP 
(see Fig. 4). The place Config models the configuration information associated 
with the edge router, and place PrefixPool models the number of prefixes still 
available in the edge router for distribution to gateways. The place PrefixAssigned 
is used to keep track of which prefixes are assigned to which gateways. 

Figure 7 shows the declarations of the colour sets for the three places in Fig. 6. 
The configuration information for the edge router (modelled by the colour set 
ERConfig) is a record consisting of the IPv6 link-local address and the link- 
layer address of the edge router. A list of pairs (colour set ERPrefixAssigned) 
consisting of a link-local address and a prefix is used to keep track of which 
prefixes are assigned to which gateways. A counter modelled by place PrefixPool 
with the colour set PrefixCount is used to keep track of the number of prefixes still 
available. When this counter reaches 0, the edge router has no further prefixes 
available for distribution. The number of available prefixes can be modified by 
changing the initial marking of place PrefixPool which is by default set to 1. 

The substitution transition SendUnsolicitedRA (in Fig. 6) corresponds to the 
multi-cast of periodic unsolicited Router Advertisements (RAs) by the edge 
router. The substitution transition ProcessRS models the reception of unicast 
Router Solicitations (RSs) from gateways, and the sending of a unicast RA 
in response. The substitution transition ERDiscard Prefixes models expiration of 
prefixes on the edge router side. 

The marking shown in Fig. 6 has a single token on each of the three places 
used to model the internal state of the edge router protocol entity. This is shown 
by the small circles positioned on top of these places and containing the integer 
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color IPv6Addr = string; (* IPv6 addresses *) 

(* Router Soliciations *) 

color RSOption = union RS_SrcLinkAddr : NDLinkAddrOption + 

RS_Pref ixlnf ormation : NDPref ixlnf ormationOption; 
color RSOptions = list RSOption; 

color RouterSolicitation = record Options : RSOptions * 

NU : NOTMOD ; 

(* Router Advertisements *) 

color RAOption = union RA_SrcLinkAddr 
RA_MTU 

RA_Pref ixlnf ormation 
color RAOptions = list RAOption; 

color RouterAdvertisement = record CurHopLimit : UInt8 * 

M : Bit * 

0 : Bit * 

RouterLif etime : UIntl6 * 
ReachableTime : UInt32 * 
RetransTimer : UInt32 * 

Options : RAOptions; 

(* ICMP messages *) 

color ICMPBody = union RS : RouterSolicitation + 

RA : RouterAdvertisement; 
color ICMPMessage = record Type : UInt8 * 

Code : UInt8 * 

Message : ICMPBody; 

(* IPv6 packets *) 

color IPv6Payload = union ICMP : ICMPMessage; 
color IPv6Header = record Version : Bit4 * 

TrafficClass : NOTMOD * 

Flowlabel : NOTMOD * 

PayloadLenght : NOTMOD * 

NextHeader : Bit8 * 

HopLimit : Bit8 * 

SourceAddress : IPv6Addr * 

color IPv6Packet = record header : IPv6Header * 

extheaders : NOTMOD * 
payload : IPv6Payload; 



NDLinkAddrOption + 
NDMTUOption + 

NDPref ixlnf ormat ionOpt ion ; 



Fig. 5. Declarations for IPv6 and ICMP packets. 
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IPv6Packet 



IPv6Packet 



Fig. 6. The EdgeRouter page. 



color LinkAddr = string; 
color PrefixCount = int; 

color ERConfig = record ll_er : IPv6Addr * (* link-local address of ER *) 

er_12 : LinkAddr; (* link-addr (layer 2) of ER *) 

color ERPref ixEntry = product IPv6Addr * IPv6Prefix; 
color ERPref ixAssigned = list ERPref ixEntry ; 



Fig. 7. Declarations for modelling edge routers. 



1. The dashed box positioned next to each of the small circles gives informa- 
tion about the colour of the token. In the marking shown, the token on place 
PrefixAssigned with the colour [] (empty list) corresponds to the edge router not 
having assigned any prefixes to the gateway. The token on place PrefixPool with 
colour 1 indicates that the edge router has a single prefix available for distribu- 
tion. Finally, the colour of the token on place Config specifies the link-local and 
link address of the edge router. In this case the edge router has the symbolic 
link-local address of ER link-local address, and the symbolic link-address of ER 
link-addr. 

Figure 8 depicts page SendUnsolicitedRA which is the subpage of the substi- 
tution transition SendUnsolicitedRA in Fig. 6. The transition SendUnsolicitedRA 
models the sending of the periodic unsolicited router advertisements. The vari- 
able erconfig is of type ERConfig (see Fig. 7) and the variable prefixleft is of type 
PrefixCount (see Fig. 7). The transition SendUnsolicitedRA is only enabled if the 
edge router has prefixes available for distribution, i.e., prefixleft is greater than 0. 
This is ensured by the function SendUnsolicitedRA in the guard of the transition. 
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Fig. 8. Page SendUnsolicitedRA - initial state. 



Figure 9 depicts the marking of page SendUnsolicitedRA after the occurrence 
of the transition SendUnsolicitedRA in the marking shown in Fig. 8. An unso- 
licited router advertisement has been put in the outgoing buffer of the edge 
router. It can be seen that the unsolicited router advertisement is sent to the all- 
nodes multi-cast address, and that it carries the link-local and link-layer address 
of the edge router as part of the options in the router advertisement. 
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Fig. 9. Page SendUnsolicitedRA - after occurrence of SendUnsolicitedRA. 
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3.3 Modelling the Wireless Link 

Figure 10 shows the part of page GW_ER_Link modelling transmission of packets 
from the edge router to the gateway across the wireless link. Transmission of 
packets from the gateway to the edge router is modelled similarly. The places 
GWIn and EROut are linked to the similarly named socket places in Fig. 4. The 
transition ERtoGW models the successful transmission of packets, whereas the 
transition LossERtoGW models the loss of packets. The variable ipv6packet is of 
type IPv6Packet. A successful transmission of a packet from the edge router to 
the gateway corresponds to moving the token modelling the packet from place 
EROut to GWIn. If the packet is lost, it will only be removed from place EROut. 

Wireless links in general have lower bandwidth and higher error-rate than 
wired links. These characteristics have been abstracted away in the CPN model 
since our aim is not to reason about the performance of ERDP but rather its 
logical correctness. Duplication and reordering of messages is not possible on 
typical 1-hop wireless links since detection of duplicates and preservation of 
order will be handled by the data-link layer. The modelling of the wireless link 
does allow overtaking of packets, but this overtaking will be eliminated in the 
analysis phase described in Sect. 4 where we impose bounds on the capacity of 
the input and output packet buffers. 




3.4 Summary of the Modelling Process 

The CPN model presented above was developed as an integrated part of the 
development of ERDP. Creation of the CPN model was done by researchers 
from the Coloured Petri Nets group whereas the development of the ERDP 
specification was done by protocol developers at Ericsson Telebit A/S. Altogether 
70 man-hours were spent on CPN modelling. The protocol developers at Ericsson 
Telebit A/S had been given a 6 hour course on the CPN modelling language. This 
course enabled them to read and interpret CPN models, allowing the CPN model 
to be used as a basis for discussions of the protocol design and its representation 
as a CPN model. 

The development of ERDP started out with the creation of an initial ERDP 
(natural language) specification. Based on this specification, a first version of 
the CPN model was created. The act of creating this initial CPN model and 
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Table 1 . Summary and categorisation of issues encountered in the modelling phase. 



Category 


Rev 1 


Rev 2 


Total 


Incompleteness and ambiguity in specification 


3 


6 


9 issues 


Errors in protocol specification/operation 


2 


7 


9 issues 


Simplifications of protocol operation 


2 


0 


2 issues 


Additions to the protocol operation 


4 


0 


4 issues 


Total 


11 


13 


24 issues 



discussing it (in the following referred to as Review 1) lead to the identification 
of several issues related to the design and operation of ERDP. This included 
design errors, incompleteness and ambiguity in the specification, and ideas for 
simplifications and improvements of the protocol design. Based on the issues 
discovered in Review 1, the ERDP specification was revised and extended. A 
second review (Review 2) was then conducted by revising the initial CPN model 
according to the modified ERDP specification and then discussing the CPN 
model. Review 2 lead to further identification of issues which were eventually 
resolved and the ERDP specification was modified accordingly. The CPN model 
was then modified again to reflect the revised ERDP specification. At this stage, 
no further issues were discovered in the process of revising the CPN model. 

Table 1 categorises and enumerates the issues encountered in each of the 
two reviews (Rev 1 and Rev 2). These issues were identified in the process 
of constructing the CPN model, single step execution of the CPN model, and 
discussions of the CPN model among the project group members. Altogether 24 
issues were identified in the process of constructing and simulating the model. 

Message Sequence Charts (MSCs) (such as the one shown in Fig. 2) integrated 
with simulation was used in both review steps to investigate the behaviour of 
ERDP in detail. The basic idea in this integration is to use MSCs to provide 
visual feedback from simulations of the CPN model. Visual feedback in the form 
of MSCs is supported by the MSC library [1] available for the CPN computer 
tools. Technically the integration of MSCs and simulation is achieved by the 
modeller attaching code segments to the transitions of the CPN model. The code 
segments invoke primitives in the MSC library. When a transition occurs in a 
simulation the associated code segment (if any) is executed causing the MSC 
to be accordingly updated. The visualisation at the level of the CPN model 
provides a state-based view whereas MSCs provides an event-based view that 
includes history. The two forms of feedback therefore complements each other. 



4 State Space Analysis and Verification 

State space analysis was pursued after the three iterations of modelling sum- 
marised at the end of the previous section. The purpose of the state space anal- 
ysis was to conduct a more thorough investigation of the operation of ERDP, 
including verification of its key properties. 
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4.1 Analysis Preparations and Approach 

The first step towards state space analysis of the CPN model was to obtain 
a finite state space. The CPN model presented in the previous section has an 
infinite state space since an arbitrary number of tokens (packets) can be put 
on the places modelling the packet buffers. As an example, the edge router 
may initially send an arbitrary number of unsolicited router advertisements. 
To obtain a finite state space, an upper bound of one token was imposed on 
each of the places GWIn, GWOut, ERIn, and EROut (see Fig. 4) modelling the 
packet buffers. This has the effect of also preventing reordering of the packets 
when transmitted across the wireless link. Furthermore, the number of packets 
simultaneously in the input and output buffers of the two protocol entities was 
limited to 2. Technically this was done by using branching options available in 
the CPN state space tool to not explore enabled transitions whose occurrence in 
a given marking would violate the above bounds. 

Figure 11 shows the initial part of the state space in the case where we assume 
that packets cannot be lost when transmitted across the wireless link. Each of the 
nodes 1-7 represent a state of the CPN model, and each of the arcs represent an 
occurrence of an enabled transition. The labels on the arcs give the name of the 
transition occurring. Node 1 represents the initial state of the CPN model. The 
two dashed boxes associated with nodes 1 and 2 show the marking of each of the 
places in the CPN model in the corresponding state. It can be seen that initially 
(node 1) all packet buffers are empty, the edge router has one prefix to assign, 
and the gateway is not configured with any prefixes. Sending of an unsolicited 
RA by the edge router is the only possible event in the initial state. If this event 
occurs, the state corresponding to node 2 is entered. The state represented by 
node 2 is identical to the state represented by node 1, except that an unsolicited 
RA is now in the output buffer of the edge router. In state 2 the unsolicited RA 
can be sent to the gateway leading to state 3 in which either another unsolicited 
RA can be sent by the edge router or the gateway can process the unsolicited RA. 

The state space analysis was based on first generating the state space for the 
considered configuration of the protocol. This was followed by generation of the 
state space report, and the use of query functions to investigate the properties of 
the protocol. The state space report can be generated automatically by the CPN 
state space tool, and it contains information about a set of standard properties of 
the CPN model such as integer bounds (minimal/maximal number of tokens on 
places), dead markings (states without enabled transitions), and home markings 
(states that can always be reached) . These properties are system independent in 
that the properties that can be investigated for any CPN model. 

The query functions in the CPN state space tool support verification and 
analysis of system dependent properties. The query functions provide a set of 
primitives for traversing the state space in various ways, such as visiting all 
states. The analysis of ERDP relied mainly on the use of the Strongly Connected 
Component graph (SCC-graplr) derived from the state space. The SCC-graplr 
is generated by the CPN state space tool and is derived from the state space 
by considering states to be equivalent if they are mutually reachable. The SCC- 
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Fig. 11. Initial fragment of state space. 



graph has a node for each such equivalence class containing the subgraph of the 
state space determined by the states in the equivalence class. A node in the SCC- 
graplr is called a Strongly Connected Component (SCC). The SCC-graplr is an 
acyclic graph, and two states Si and S2 are in the same SCC S in the SCC-graplr 
if and only if there is a path from si to S2 and a path from S2 to si in the state 
space. There is an arc in the SCC-graplr between two SCCs S i and S2 if there 
is a state si in Si with an outgoing arc in the state space leading to a state S2 
contained in S2 ■ The terminal SCCs are the nodes in the SCC-graplr without 
outgoing arcs. A SCC is trivial if it contains one state and no arcs. A number 
of query functions are available in the CPN state space tool for inspecting and 
traversing the SCC-graplr. 

The key property of ERDP is the proper configuration of the gateway with 
prefixes. By this we mean that for a given prefix and state where the gateway 
has not yet been configured with that prefix, the protocol must be able to con- 
figure the gateway with the prefix. Furthermore, when the gateway has been 
configured with the prefix, the edge router and the gateway should be properly 
synchronised, i.e., the assignment of the prefix must be recorded in the gateway 
protocol entity as well as in the edge router protocol entity. In the following we 
will refer to a state where the gateway is configured with a prefix and the edge 
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router and gateway is synchronised as a consistently configured state for that 
prefix. Whether a state represents a consistently configured state for a given 
prefix can be checked by inspecting the marking of the place PrefixAssigned in 
the edge router and the marking of the place Prefixes in the gateway. 

The state space analysis was conducted in three steps starting with the sim- 
plest configuration of the protocol where no packet loss and no expiration of 
timers are allowed. The simplifications were then gradually lifted. 

4.2 Step 1: Basic Configurations 

The first step was to consider the simplest possible configurations of ERDP 
starting with a single prefix and assuming that there is no loss of packets on 
the wireless link and that prefixes do not expire. The full state space for this 
configuration has 46 nodes and 65 arcs and was generated in less than one 
second on a Linux PHI PC with 1Gb of memory. The SCC-graplr has 36 nodes 
and 48 arcs. Having constructed the state space and computed the SCC-graplr, 
the standard state space report can be generated. Inspection of the state space 
report showed that there was a single dead marking (a state without enabled 
transitions) represented by node 36. Hence the state represented by node 36 
corresponds to a state where the protocol has terminated. Inspection of node 36 
showed that it corresponded to a state where all the packet buffers were empty, 
but where the edge router and gateway are unsynclrronised in the sense that 
the edge router is in a state where the gateway is assigned prefix PI (the single 
prefix), but the gateway is not configured with that prefix. This is an error in 
the protocol. To locate the source of the problem, query functions in the state 
space tool were used to obtain a path (i.e., an error-trace or counter example) 
leading from the node representing the initial state to node 36. Figure 12 shows 
this error-trace visualised using a MSC. The integration of message sequence 
charts in the CPN computer tools makes it possible to automatically display a 
path in the state space as an MSC. The problem is that the edge router sends 
two unsolicited RA. The first one gets through and the gateway is configured 
with the prefix (Event A). However, when the second RS (Event B) without any 
prefixes is received by the edge router, the corresponding solicited RA will not 
contain any prefixes. Because of the way the protocol was specified, the gateway 
will therefore update its list of prefixes to the empty list (Event C), and the 
gateway is no longer configured with a prefix. 

To fix the error identified, the protocol was modified such that the edge router 
always replies with the list of all prefixes that it has currently assigned to the 
gateway. The state space for the modified protocol contains 34 nodes and 49 
arcs, and there are no dead markings in the state space. The state space report 
specifies that there are 11 home markings. Hence, the protocol has the property 
that any of the corresponding 11 states can always be reached. Inspection of these 
11 states showed that they all represented consistently configured states for the 
prefix PI. The states are contained in the single terminal SCC of the state space. 
When the SCC-graplr has a single terminal SCC, it is always possible to reach 
one of the states in that terminal SCC and once having entered a state in the 
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Fig. 12. MSC showing execution leading to undesired terminal state. 



terminal SCC, the system can only enter states in the terminal SCC. This shows 
that when executing ER.DP starting from the initial state it is always possible 
to reach a consistently configured state for the prefix, and when such a state 
has been reached, the protocol entities will remain in a consistently configured 
state. To verify that a consistently configured state will eventually be reached, 
it was checked that the single terminal SCC was the only non-trivial SCC. This 
shows that all cycles in the state space (which correspond to non-terminating 
executions of the protocol) are contained in the terminal SCC which (from above) 
contains only consistently configured states. The reason why the protocol is not 
supposed to terminate in a consistently configured state represented by a dead 
marking is that the gateway may at any time when it is configured send a router 
solicitation back to the edge router to have its prefixes refreshed. Since we ignore 
expiration of prefixes, the edge router will always refresh the prefix. 

The number of prefixes was increased once the correctness of the protocol 
was established for a single prefix. When there is more than one prefix available 
it no longer holds that a state will eventually be reached where all prefixes are 
consistently configured. The reason is that with more than one prefix, the edge 
router may at any time decide not to configure the gateway with additional 
prefixes. Hence, a state where all prefixes have been consistently configured may 
not eventually be reached. Instead it was verified that there was a single terminal 
SCC of which all states are states where all prefixes have been consistently 
configured. This shows that it is always possible to reach such a state, and when 
the protocol has consistently configured all prefixes, the protocol entities will 
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Table 2. State space statistics for basic configurations. 



IPI 


Nodes 


Arcs 


G-time 


A-time 


1 


34 


49 


0.05 


0.01 


2 


72 


121 


0.11 


0.01 


3 


110 


193 


0.18 


0.01 


4 


148 


265 


0.28 


0.01 


5 


186 


337 


0.38 


0.01 


6 


224 


409 


0.50 


0.02 


7 


262 


481 


0.62 


0.02 


8 


300 


553 


0.76 


0.03 


9 


338 


625 


0.93 


0.03 


10 


376 


697 


1.15 


0.04 



remain consistently configured. Secondly, it was checked that all states in each 
non-trivial SCC represented states where the protocol entities were consistently 
configured with a subset of the prefixes available in the edge router. 

Table 2 lists the statistics for the state space generation for different number 
of prefixes. The |P| column specifies the number of prefixes. The Nodes and Arcs 
columns give the number of nodes and arcs in the state space, respectively. The 
G-time column gives the time in seconds used to generated the state space, and 
the A-time column gives the time in seconds used to conduct the verification of 
properties presented above. It can be observed that 38 states are added for each 
additional prefix. The reason for this is that ERDP proceeds in phases where 
the edge router assigns prefixes to the gateway one at a time. Configuring the 
gateway with an additional prefix follows exactly the same procedure as the 
assignment of the first prefix. It can be seen that once the state space has been 
generated, the verification of properties could be done in less than one second. 

4.3 Step 2: Adding Packet Loss 

Next we considered state space analysis in presence of packet loss on the wireless 
link between the edge router and the gateway. First we considered the case where 
there is only a single prefix for distribution. The state space for this configuration 
has 40 nodes and 81 arcs. Inspection of the state space report showed that there 
was a single dead marking. This state represented an undesired terminal state 
where the prefix was assigned by the edge router according to its internal state, 
but the gateway was not configured with this prefix. Figure 13 shows an MSC 
corresponding to the path in the state space from the initial state to the undesired 
terminal state. The problem is that when the unsolicited RA containing the 
prefix is lost, the edge router will have assigned its last prefix and is no longer 
sending any unsolicited RAs. Furthermore, there are no timeouts in the protocol 
entities that can trigger the retransmission of the prefix to the gateway. 

The problem identified above was fixed by ensuring that the edge router will 
resend an unsolicited RA to the gateway as long as it has prefixes assigned to 
the gateway according to its internal state. The state space of the revised CPN 
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Fig. 13. MSC showing execution leading to undesired terminal state. 



model has 68 nodes and 160 arcs. Inspection of the state space report showed 
that there were no dead markings and no home markings. Investigation of the 
terminal SCCs showed that there were two terminal SCCs each containing 20 
states. The nodes in one of them all represented states where the edge router 
and gateway were consistently configured with the single prefix PI, whereas 
the nodes in the other terminal SCC all represented states where the protocol 
entities were not consistently configured. The states in the undesired terminal 
SCC hence represent a livelock in the protocol, i.e., if one of the states in the 
undesired terminal SCC is reached, it is no longer possible to reach a state where 
the protocol entities are consistently configured with the prefix. The source of 
livelock was related to the control fields used in the router advertisements for 
refreshing prefixes and their interpretation in the gateway. This was identified by 
obtaining the MSC for a path leading from the initial state to one of the states in 
the undesired terminal SCC. As a result, the processing of router advertisements 
in the gateway was modified. The state space for the protocol with the modified 
processing of router advertisements also has 68 nodes and 160 arcs. The state 
space has a single terminal SCC containing 20 nodes which all represents states 
where the protocol entities are consistently configured with the single prefix. 

When packet loss is present, it is not immediately possible to prove that the 
two protocol entities will eventually be consistently configured. The reason is 
that any number of packets can be lost on the wireless link. Each of the non- 
trivial SCCs were inspected using a query function to investigate the circum- 
stances under which the protocol entities would not eventually be consistently 
configured. The query function checked that either all nodes in the non-trivial 
SCC represented consistently configured states or none of the nodes in the SCC 
represented a consistently configured state. For those non-trivial SCC where no 
node represented a consistently configured state, it was checked that all cycles 
contained the occurrence of a transition corresponding to loss of a packet. Since 
this was the case, it can be concluded that the absence of reaching a consistently 
configured state is due to packet loss and nothing else. Hence, if only finitely 
many packets are lost, a consistently configured state will eventually be reached. 
Table 3 gives statistics on the state space for verification of properties. 
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Table 3. State space statistics for packet loss configurations. 



IPI 


Nodes 


Arcs 


G-time 


A-time 


1 


68 


160 


0.11 


0.01 


2 


172 


425 


0.34 


0.02 


3 


337 


851 


0.87 


0.08 


4 


582 


1489 


1.48 


0.16 


5 


926 


2390 


2.67 


0.32 


6 


1388 


3605 


4.48 


0.67 


7 


1987 


5185 


6.66 


1.34 


8 


2742 


7181 


9.99 


2.65 


9 


3672 


9644 


14.15 


4.86 


10 


4796 


12625 


19.93 


10.17 



4.4 Step 3: Adding Expire of Prefixes 

The final step in the analysis was to allow prefixes to expire. The analysis was 
conducted first in the configuration where the edge router has only a single 
prefix to distribute. The state space for this configuration has 173 nodes and 
513 arcs. The state space has a single dead marking, and inspection of this dead 
marking showed that it corresponded to a state where the edge router has no 
further prefixes to distribute, it has no prefixes recorded for the gateway, and the 
gateway is not configured with any prefix. This marking is a desired terminating 
state of the protocol, as we expect prefixes to eventually expire. Since the edge 
router has only finitely many prefixes to distribute the protocol should eventually 
terminate in such a state. The single dead marking is also a home marking, 
meaning that the protocol can always enter the expected terminal state. 

When prefixes can expire the two protocol entities may never enter a consis- 
tently configured state. The reason is that a prefix may expire in the edge router 
(albeit unlikely) before the gateway has successfully been configured with the 
prefix. Hence, we are only able to prove that for any state where a prefix is still 
available in the edge router, it is possible to reach a state where the gateway 
and the edge router are consistently configured with this prefix. Table 4 lists the 
statistics for the state space generation and verification of properties in the case 
where expire of prefixes is also taken into account. 

5 Conclusions 

We have described how CPN modelling and state space analysis have been ap- 
plied in the process of developing ERDP. Already the act of constructing the 
CPN model based on the ERDP specification provided valuable input to the 
ERDP specification, and the use of simulation added further insight into the 
operation of the protocol. State space analysis starting with the simplest pos- 
sible configuration of the protocol identified additional errors in the protocol. 
The state space analysis succeeded in establishing the key properties of ERDP. 
The main drawback of verification based on state spaces is the state explosion 
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Table 4. State space statistics for prefix expire configurations. 



IPI 


Nodes 


Arcs 


G-time 


A-time 


1 


173 


531 


0.34 


0.02 


2 


714 


2404 


1.80 


0.17 


3 


2147 


7562 


6.34 


0.67 


4 


5390 


19516 


18.65 


2.09 


5 


11907 


43976 


48.56 


6.39 


6 


23905 


89654 


121.07 


15.36 


7 


44550 


169169 


289.91 


33.14 


8 


78211 


300072 


671.24 


64.12 


9 


130732 


505992 


1560.73 


123.81 


10 


209732 


817903 


3586.23 


229.70 



problem [28]. However, for the verification of ERDP presented in this paper the 
state explosion problem was not encountered and we succeeded in verifying the 
key properties of the ERDP protocol for the configurations that are envisioned 
to occur in practice. The verification presented in this paper considered the case 
with one gateway and one edge router. As part of future work we plan to con- 
sider verification in the presence of multiple gateways and edge routers. When 
considering multiple gateways and edge routers we are likely to encounter the 
state explosion problem. The symmetry method [19] and sweep-line method [2] 
are promising candidates for alleviating the state explosion problem in that case. 

It can be argued whether or not the issues and errors discovered in process 
of modelling and conducting state space analysis would have been identified if 
additional conventional reviews of the ERDP specification had been conducted. 
Some of them probably would, but more subtle problems such as the synchro- 
nisation issues discovered during state space analysis would probably not have 
been discovered until a first implementation of ERDP was operational. The rea- 
son for this is that discovering these problems requires one to consider subtle 
execution sequences of the protocol, and there are too many of these to do it in a 
systematic way. This demonstrates the value of being able to conduct state space 
exploration of the CPN model and in this way cover all execution sequences. 

The construction of a CPN model can be seen as a very thorough and sys- 
tematic way of reviewing a design specification of a protocol. Using an iterative 
process where both a conventional natural language specification and a CPN 
model is developed (as in this project) appears to be an effective way of in- 
tegrating CPN modelling and analysis into the development of a protocol. In 
general, we believe that a combination of an executable formal model (such as 
a CPN model) and a natural language specification is a useful specification of a 
protocol. One reason that both are required is that the people who are going to 
implement the protocol may not be familiar with CP-nets. Secondly, there are 
important parts of the ERDP specification that are not reflected in the CPN 
model, such as the layout of packets. Similar observations were also made in [24] 
for the design of a security system. 
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In the project, we have demonstrated the use of message sequence charts 
(MSCs) for visualising the behaviour of the protocol based on simulations and 
based on paths in the state space. The automatic creation of MSCs based on 
executions of a CPN model is different from the conventional use of MSCs as 
a specification technique. The event-based graphical feedback in the form of 
MSCs has the advantage that it provides a compact view of the steps, i.e., how 
the current state of the protocol was reached. In contrast, the conventional state- 
based visualisation of the token distribution on the CPN model only shows the 
current state and it is distributed across several pages (modules). The use of 
MSCs in this project was of particular relevance since it presented the operation 
of the protocol in a form well-known to protocol developers. 

We consider the application of CP-nets in the development of ERDP a suc- 
cess for three main reasons. Firstly and as in earlier case studies [16], we have 
demonstrated that the CPN modelling language and supporting computer tools 
are powerful enough to specify and analyse a real-world communication proto- 
col. Secondly, the act of constructing the CPN model, executing, and discussing 
it lead to the identification of several non-trivial design errors and issues that 
under normal circumstances would not have been discovered until at best in the 
implementation phase. Finally, the effort of constructing the CPN model and 
conducting the state space analysis was approximately 100 man-hours. This is a 
relatively small investment compared to the many issues that were identified and 
resolved early as a consequence of constructing and analysing the CPN model. 
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Abstract. In this paper we summarize syntax and semantics of modules of ele- 
mentary signal nets and explain how to synthesize the control for discrete event 
systems modelled by such modules. 

Signal nets, introduced in [8,9,10,12], are based on Petri net modules which 
communicate via signals. Two kinds of signals are employed, namely active sig- 
nals which force occurrence of (enabled) events, and passive signals which en- 
able/prohibit occurring of events. Modelling with such modules appears to be 
very natural from an engineering perspective. It enables hierarchical structuring 
and supports the locality principle. 

Given an uncontrolled system (a plant), modelled by a module of an elementary 
signal net, and a control specification, given as a regular language representing 
the desired signal output behavior of this system, we show step-by-step how to 
automatically synthesize the maximally permissive and nonblocking behavior of 
the plant respecting the control specification. Finally, we show how to synthesize 
the controller (as a module of an elementary signal net) forcing the plant to realize 
the controlled behavior. 



1 Introduction 

In complex applications, models are usually constructed in several steps and are de- 
scribed on several levels of abstraction. Systems are parts of bigger systems, such as a 
robot is a part of a manufacturing cell. Conversely, many systems are composed from 
subsystems. This fact motivates the principle of modularity and compositionality. Con- 
sidering a certain level of abstraction, one does not need to reason about all details of 
subsystems which were taken into consideration on a sublevel. It is usually sufficient to 
consider just those parts of subsystems which are in contact with the environment, i.e, 
the "input/output" parts and to consider the "inside" of the subsystems being a "black 
box". Such an approach supports local changes in the whole system, i.e. it enables the 
replacement of one subsystem by another with the same "input/output"-functionality. 

Considering discrete event systems (DES), Petri nets are a very successfully suc- 
cessfully used modelling formalism [13,29]. The main reason is that they offer both. 
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nice graphical representation and formal background. In addition, modelling with Petri 
nets is popular because Petri nets usually allow a more compact and structured rep- 
resentation of the system behavior than automata. There are many case studies using 
Petri nets in modelling and control and many tools supported by sophisticated analytical 
methods. However, Petri nets (at least in their basic version) do not support the above 
mentioned features which are very essential for engineering applications: The absence 
of input/output structure seems to be a strong limitation. Additionally, the important 
feature of hierarchical structuring is not directly supported by Petri nets. 

There are many compositional frameworks for Petri nets, mostly based on gluing 
common places and/or transitions. However, it is desirable that the composition 
of modules preserves the structure of modules. Modules of signal nets constitute 
an extension of Petri nets which supports input/output structuring, modularity and 
compositionality in an intuitive graphical way. This formalism was developed in a 
series of papers under the name net condition/event system and is widely used for 
modelling of complex DES, see e.g. [9,10,12]. A signal net is a Petri net enriched by 
event signals , which force the occurrence of (enabled) events, and condition signals 
which enable/prohibit the occurrence of events. Adding input and output signals to a 
signal net, one gets a module of a signal net. Modules of signal nets can be composed 
by connecting their respective input and output signals. 

In the first part of this paper we summarize syntax and semantics of modules of 
elementary signal nets, where the underlying Petri nets are elementary Petri nets. In the 
second part, we give a survey on control synthesis for DES modelled by modules of 
elementary signal nets. In this part technical details are replaced by illustrations (for a 
detailed presentation see [18,19]). Furthermore, a brief comparison to the supervisory 
control synthesis approach based on automata is provided. 

In the problem of control synthesis for DES, a system is given which can interfere with 
its environment via inputs and outputs. This is the object to be controlled, and it is called 
"plant". The goal of control is to ensure a specified behavior of this plant which is given 
as a set of desired sequences of inputs and outputs. The plant is therefore equipped with 
sensors that provide information about some (usually not all) so called obsen’able states 
and state transitions of the plant. It is also equipped with actuators that allow to control 
the behavior of the plant by enforcing or preventing some (usually not all) so called 
controllable state transitions in the plant. The central idea is that plant and control build 
a so called closed loop {ox feedback loop ) which means, roughly speaking, that the control 
gives inputs to the actuators of the plant based on the observed sensor outputs of the plant. 

Modelling a plant by a module of a signal net, sensors in the plant may provide 
condition signals to give information about a reached observable state to the control. For 
example, a condition signal can indicate that a process variable of the plant is within 
a given range of its value. Sensors in the plant may also provide event signals to give 
information about the occurrence of an observable state transition to the control. For 
example, it can be indicated by an event signal that a process variable in the plant is just 
reaching a threshold. 

A controller that controls the plant may use both types of signals as well. Via 
condition signals, the controller prohibits/enables controllable state transitions in the 
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plant whereas via event signals, the controller tries to force controllable state transitions 
in the plant to occur. 

In [18,19], we identify which event signal inputs have to be sent to the plant mod- 
ule in order to observe only such sequences of event signal outputs which are prefixes 
of and can be completed to sequences of event signal outputs belonging to the control 
specification. This control specification is given as a regular language. The resulting 
output behavior of the plant is maximal with this properties. In other words, we con- 
struct a language over event signal inputs and outputs of the module of the plant which 
represents the maximally permissive nonblocking controllable behavior satisfying the 
control specification. Finally, we show in [19] that for such a behavior there exists a 
control module (of a signal net) which, composed with the plant module, realizes this 
behavior. As the main result of [19], we construct such a control module. 

The formal definitions in [18,19] are based on low-level Petri nets, where tokens 
carry no data structure. In particular, the interfaces and the communication between 
modules are low-level. These elementary signal net models are close to the physical 
level (similar to assembler code in the area of programming languages). Of course, one 
can achieve more compact representations (for example of protocols, services, data types 
et cetera) by using appropriate high level concepts (such as high-level Petri nets in this 
case). However, the fundamental problems arising in controller synthesis considered in 
[18,19] (such as observability and controllability of behavior) are of low-level nature. 
For real applications, a higher-level modelling language would be more suitable. In [5] 
we present such a language based on signal nets extended by high-level features (such 
as data types, annotated condition signals, timers etc.) and employed it in a case study 
from automotive industry (modelling of controllers for the new AUDI A8 model). 

Several related work employs modules of signal nets in the control of discrete event 
systems. In [9,10,12] effective solutions for particular classes of specifications, such as 
forbidden states, or simple desired and undesired sequences of events are described. An 
approach for control specification given by cycles of observable events was presented in 
[21]. Up to recent time, the problem of control synthesis for the general class of specifica- 
tions given by regular languages (as in supervisory control theory for systems modelled 
by automata) remained open for modules of signal nets. In [19], we filled this gap. 

The paper splits into two parts: In the first part we present modules of elementary 
signal nets with definition of step semantics, composition rules and input/output behav- 
ior. In the second part we illustrate control synthesis of DES with modules of elementary 
signal nets: In Subsection 3.1 we show how to automatically synthesize the maximally 
permissive nonblocking controllable behavior of a module of a signal net (representing 
the plant) respecting a given regular specification language. In Subsection 3.2 we present 
how to construct the controller as a module of a signal net. Finally, we take a short view 
on methods that use the structure of some models rather than the complete enumeration 
of the state space in Subsection 3.3. A conclusion and an outlook on further work is 
given in Section 4. 




A Guide to Modelling and Control with Modules of Signal Nets 



273 



Part I 

2 Modules of Signal Nets 

As mentioned in the introduction, we use an extension of elementary Petri nets (1-safe 
Petri nets) which allows to model condition and event signals, supports modularity, and 
preserves the essential benefits of Petri nets. We assume the underlying elementary Petri 
nets to be equipped with the so called first consume, then produce semantics (since we 
allow loops, see e.g. [16]). The first step of the extension is to add two kinds of signals, 
namely active signals which force the occurrence of (enabled) transitions, and passive 
signals which enable/prohibit the occurrence of transitions. These signals are represented 
respectively by two kinds of arcs. A Petri net extended with such signals is simply called 
a signal net. 

Active signals, also called event arcs, are represented by arcs connecting transitions. 
They are interpreted in the following way: An event arc leading from transition t\ to 
transition 1 2 specifies that, if transition l \ occurs and transition 1 2 is enabled to occur then 
the occurrence of f 2 is forced (synchronized) by the occurrence of l \ , i.e. then transitions 
ti and i 2 occur in one (synchronized) step. If f 2 is not enabled, t\ occurs without f 2 > 
while an occurrence of i 2 without t \ is not possible. As an example, an event turning on 
a switch would be modelled via transition t -\ , while the event lighting the bulb would be 
modelled via transition f 2 . 

In general, (synchronized) steps of transitions are defined inductively in the above 
way. Every step starts at one so called spontaneous transition which is not synchronized 
by another transition. It is required that there are no cycles of event arcs. 

Consider a transition t which is synchronized by transitions t \ , . . . , t n , n ^ 2. Then 
there are two dialects in the literature to interpret such a situation. For simplicity we 
consider the case n = 2. In the first approach [9,10,12] both transitions t-\ and f 2 have 
to agree to synchronize t. Thus the only possible step of transitions involving t has to 
include transitions t\ and f 2 , too. We call this dialect AiVD-semantics (see Figure 1, 
part (b)). In the second one [4] the occurrence of at least one of the transitions t \ and i 2 
synchronizes transition t, if t is enabled. We call this dialect ////-semantics (see Figure 
1, parts (a) and (c)). 

In general, the relation given by event arcs builds a forest of arbitrary depth. We 
introduce the most general interpretation, where we distinguish between OR- and AND- 
synchronized transitions. An ////-synchronized transition demands to be synchronized 
by at least one of its synchronizing transitions, whereas an A ND -synchronized transition 
demands to be synchronized by all of its synchronizing transitions. Since we allow 
loops w.r.t. single transitions, i.e, transitions connected to a place with flow arcs in both 
directions, we also allow loops w.r.t. steps of transitions (see Figure 2, part (a)). 

Passive signals are expressed by so called condition arcs (also called read arcs or test 
arcs in the literature) connecting places and transitions. A condition arc leading from a 
place to a transition models the situation that the transition can only occur if the place 
is in a certain state but this state remains unchanged by the transition’s occurrence (read 
operation) (see Figure 2, part (b)). There are no condition arcs leading from a transition 
to a place. Several transitions belonging to a synchronized step can test a place to be in a 




274 



J. Desel et al. 



(•MZJ-'O 




«[* 



(a) 




(sKiK) 









(c) 



Fig. 1. In (a) the enabled steps are {ti,t} and {t2 , t} . (b) shows a signal net with A/VD-semantics: 
Here the only enabled step is {/', H}, i.e. t is not synchronized. In (c) the same net is shown in 
Oi?-semantics: Here we have the enabled step {t' , i.e. t is synchronized. 
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Fig. 2. (a) shows an enabled step {fi, t}. The left part of (b) shows an enabled transition t which 
tests a place if it is marked. The occurrence of t leads to the marking shown in the right part of 
(b). Figures (c) and (d) again present situations of an enabled step (fi, /}. 



certain state via passive signals simultaneously since the state of this place is not changed 
by their occurrence (see Figure 2, part (c)). We also allow that a transition belongs to 
a synchronized step of transitions testing a place to be in a certain state via a passive 
signal, whereas the state of this place is changed by the occurrence of this or of another 
transition in this step. That means we use the so called a priori semantics [15] for the 
occurrence of steps of transitions, where testing of states precedes changing of states by 
occurrence of steps of transitions (see Figure 2, part (d)). 

As usual, places, transitions and the flow relation are drawn using circles, boxes and 
arrows respectively. To distinguish between OR- and .liV/J-synchronized transitions, 
/LA /Asynchronized transitions are additionally labelled by the symbol ”&”. Event arcs 
and condition arcs are visualized using arcs of a special shape, as shown in Figure 1 and 
Figure 2. 

Let a; be a place or a transition: *x is the set of transitions (places) connected with x 
by an arc ingoing to x, called preset of x. x* is the set of transitions (places) connected 
with x by an arc outgoing from x, called postset of x. For a transition t, we denote in a 
similar fashion: + t is the set of places which are tested on presence of tokens by t (via 
a condition arc), called the positive context of t. Given a set £ C T of transitions, we 
extend the above notations to *£, £* and + £ via the union of sets. 

A transition t is enabled at a marking m if all places in *t and + t are marked and 
the places in t* \ *t are unmarked at m. 
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A (synchronized) step of transitions is a set of transitions which can be constructed 
inductively in the following way: For each spontaneous transition t the set {£} is a 
step. If £ is a step, t is an (7 /Asynchronized transition not in £ and £ contains at least 
one synchronizing transition of t, then £ U {/} is a step. If £ is a step, t is an AND- 
synchronized transition not in £ and £ contains all synchronizing transition of t, then 
£ U {£} is a step. 

A step £ is potentially enabled at a marking m if 

- all places in *£ and + £ are marked at to, 

- the places in £* \ ( *£ U + £) are unmarked at to, and 

- all transitions A, / 2 G £ are not in conflict w.r.t. to their pre- or postsets, i.e. (~l 
•f 2 = 0 and £* (~l f* = 0- 

From all steps potentially enabled at a marking m only those are enabled which are 
maximal with this property. 

The occurrence of an enabled step £ removes a token from each place of the preset 
of £ and adds a token to each place of the postset of £. A sequence of steps which are 
enabled subsequently from the initial marking is called an occurrence sequence. 

We add to a signal net an input/output structure. This structure consists of sets of 
event signal inputs and outputs, condition signal inputs and outputs, and arcs connecting 
these inputs and outputs with places and transitions of the signal net. The event signal 
inputs and outputs are connected via event arcs with transitions of the signal net. The 
condition signal inputs are connected with transitions of the signal net via condition arcs. 
The condition signal outputs are connected with places of the signal net via condition 
arcs. For the condition signal inputs, their initial states are fixed (either in on- or off- 
state). A signal net together with such an input/output structure defines a module of a 
signal net (see Figure 3). 

We extend the notions of preset, postset and positive context to the added event and 
condition signal inputs and outputs in the obvious way. 

Two modules A and B can be composed by identifying event resp. condition inputs 
of module A one by one with event resp. condition outputs of module B, and vice versa, 
employing a composition mapping 17 (see Figure 4). The identification of inputs and 
outputs via 17 is required to satisfy the following properties: 

- A place of A connected to a transition of B via a condition signal output of A which 
is identified with a condition signal input of B is initially marked if and only if the 
condition signal input is in on-state, and vice versa. 

- No cycles of event arcs are generated. 

The connections of places and transitions of one module to places and transitions of the 
other module via identified inputs and outputs are replaced by direct signal arcs (see 
Figure 5). The composition of A and B w.r.t. Q is denoted by A B. 

We are interested in the behavior of a module of a signal net A w.r.t. a given envi- 
ronment: Transitions connected by an event signal input to the environment are not able 
to occur spontaneously but need to be synchronized by the event input in order to occur. 
Similar, a transition connected by a condition signal input to the environment is only 
able to occur if the condition signal input is in on-state. In the most general case, this 
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Fig. 3. A module of a signal net with condition inputs C ln = {c^}, event inputs E ln = 
{e^j l5 e^ 2 }> condition outputs C out = {c^} and event outputs E out = e°J^ 2 }. 




Fig. 4. The composition of two modules. 
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Fig. 5. The result of the composition of the modules from Figure 4. 



environment is assumed to be maximally permissive in the sense that there are no causal 
dependencies between sending event signal inputs and switching on and off condition 
signal inputs. We model such an environment as a module £ of a signal net and then 
compose the environment module appropriately with the module A such that £ realizes 
a maximally permissive environment in the following sense (see Figure 6): 

- At any moment, £ can send event signal inputs to A: each event signal input of A 
is synchronized by a corresponding so called input transition in £ that is always 
enabled; 

- at any moment, £ can send condition signal inputs to A: Each condition input of 
M is switched on resp. off by marking resp. unmarking a corresponding so called 
input place in £ ; 

- £ can observe signal outputs of A: Every event signal output of A synchronizes a 
corresponding so called output transition in £ that is always enabled. Every condition 
signal output enables resp. disables a corresponding output transition in £ that is 
always enabled. 

By this definition, in £ no synchronization between its transitions is allowed. In particular, 
input signals can not be sent in steps from £ to A, and output signals of A can only be 
observed by £ and not synchronize input signals of A via £. 

The assumption that the environment (which later becomes the controller) changes 
at most one of its inputs to the plant at each moment does not always hold in practice. 
A controller might change more than one input to the plant within one cyclic run of its 
control program. In such a case, an environment enabling steps of input signals has to be 





278 



J. Desel et al. 




Fig. 6. The composition of the module in Figure 3 with its maximally permissive environment 
module. 



considered. It is straightforward to modify all synthesis algorithms presented in the next 
part of this paper in order to deal with an environment allowing such steps of inputs. 

The composition of A with its maximally permissive environment £ is called the 
standalone of A. This composition has empty input/output structure. As an example, see 
Figure 7. The standalone is a model representing the uncontrolled behavior of the plant. 
The set La of all occurrence sequences of the standalone of A is called the behavior of A. 

Since the underlying Petri net is assumed to be 1-safe, the behavior La of A is a 
regular language and can be represented as a finite automaton. 

In [17] we introduced the input/output behavior of A as the set of all occurrence 
sequences of the standalone of A in which the transitions of A are hidden. Further, we 
defined two modules to be input/output equivalent if they have the same input/output 
structure and identical input/output behavior. By defining an appropriate composition 
operation for standalones, we showed that input/output equivalence is preserved by the 
composition of modules. This is a crucial concept for hierarchical modelling which 
allows to replace a module by a more abstract/concrete module with the same "in- 
put/output" functionality. Moreover, using the composition operation for standalones, it 
can easily be seen that the input/output behavior of the composition of two modules A 
and B can be represented by the composition of the standalones of A and B. 

Summarizing, modules of signal nets are an extension of Petri nets supporting in- 
put/output structures, modularity and compositionality in an intuitive graphical way with 
precise syntax and semantics. This fact gives a motivation for a more detailed theoretical 
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Standalone of A 




Fig. 7. The standalone of the module of a signal net in Figure 3. 



investigation of this extension of Petri nets. In the following part of the paper we discuss 
the role of both kinds of signals in control tasks and we focus on control aspects in 
general. 



Part II 

3 Controller Synthesis 

As mentioned in the introduction, the aim in control synthesis of DES is to influence the 
behavior of a system by a control via passive and active signals in order to get a specified 
desired behavior. In principle, there are two possibilities to specify a desired behavior 
(see [2] for an actual survey, and [1,28] for recent developments): 

- The event-based approach used in the seminal work of Ramadge and Wonham on 
supervisory control of DES [23]. In this framework, automata are used to model 
the behavior of the plant and of the control. The desired behavior is given by legal 
sequences of events. 

- The state-based approach [13], where Petri nets are used to model plant and control. 
The desired behavior is derived from a set of legal resp. forbidden states. 

In both approaches, the main problem is that the considered modelling formalism 
(languages, automata, Petri nets) does not provide a straightforward mechanism for 
enforcing events in the plant. 
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Fig. 8. Model of the plant. 



In classical supervisory control, this problem is solved by modelling the enforcing 
of an event in the plant via prohibiting all other possible events [6]. As a consequence, 
the behavior of the plant cannot be forced by the control, now called supervisor, but only 
be restricted. Formally, a regular prefix closed language over a set of events representing 
the uncontrolled behavior of the plant and a regular subset of this language representing 
the restricted desired behavior is given. In the most general case, one distinguishes be- 
tween controllable events (which can be prohibited by the supervisor) and uncontrollable 
events, and between observable events (which can be observed by the supervisor) and 
unobservable events. The question is, which controllable events should be prohibited by 
the supervisor after observing a certain sequence of observable events in order to disable 
all undesired behavior in a minimal restrictive way. 

We present an alternative to the existing approaches to control of DES, employing 
direct enforcing of events in our models. The aim of control is to maximally force the 
behavior of the plant in order to ensure the specified desired behavior. Our formalism 
is suitable for both kinds of specifications of the desired behavior. In the literature, the 
event-based approach is further developed than the state-based approach in the sense 
that it allows more general specifications [30]. Therefore, we concentrate in this paper 
on an event-based specification of the desired behavior. 

As an illustrative running example, consider the model of a plant consisting of two 
modules A and B given in Figure 8. The modules are independent. Each module models 
a task. The behavior of a module is cyclic and consists of three events. The event t ± (resp. 
£ 4 ) occurs if it is synchronized by the event signal try a (resp. tryf) and if the module is 
ready to start (place p\ (resp. pf) is marked). The event £2 (resp. £ 5 ), which represents 
that the task is finished, is spontaneous but can be observed through occurrence of the 
event signal a (resp. b). Finally, the event £3 (resp. £ 6 ), which initializes the module to 
be ready to start, is spontaneous and unobservable. 

In the figures we draw the two modules separately but we understand them as one 
module, obtained by a composition with an empty composition mapping. In other words, 
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Fig. 9. Model of the plant together with its environment. 



we consider the module obtained by putting the both modules side-by-side without 
connections between their input/output signals. We call this module V. 

The aim of the control specification is to coordinate the behavior of both modules in 
order to ensure the following behavior: Both tasks alternate strictly, starting with the task 
of module A and ending with the task of module B. More precisely, since only output 
behavior is relevant, the aim is to observe desired sequences of event output signals. 
The set of desired sequences is given by the regular language L c = (ab)* . In general, 
the desired behavior is given by a regular language which involves event signal inputs. 
Moreover, since the event arc relation produces a semantics of (synchronized) steps of 
transitions, the desired behavior must be specified as a regular language over steps of 
event signal inputs and outputs. 

Let T = {t i, . . . , te} be the set of transitions and P = {pi, . . . ,p§} be the set 
of places of the plant. To denote a marking in figures, we use the vector-like notation, 
which is more usual in control literature. 

Consider the maximally permissive environment £ of V, shown in Figure 9, and 
the standalone of V, shown in Figure 10, which is a composition of V and £ w.r.t. to a 
composition mapping 17. We denote by I = { tt ry _ a , ttry.b} the set of input transitions 
of £ corresponding to the event signal inputs tryM , tryJj and by O = { t a , h} the set 
of output transitions of £ corresponding to the event signal outputs a, b. The behavior 
L-p of V is given as the set of all occurrence sequences of the standalone of V . It can be 
represented by the finite automaton shown in Figure 1 1 . In order to be able to compare 
L-p with the specification (ab)*, we restate the specification in the form L c = ( t a tb )*, 
replacing event signal outputs by the corresponding output transitions in £ . 

A sublanguage K of Lp satisfies the specification if each occurrence sequence of 
K is a prefix of an occurrence sequence of K whose projection onto the set O of output 
transitions of £ is a string in L c . In particular, each projection of an occurrence sequence 
of K onto O is required to be a prefix of a string in L c . The above condition implies 
that K represents a nonblocking behavior where the tasks specified by L c always can 
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Standalone 




Fig. 10. Standalone of the plant. 



Behavior 




Fig. 11. Behavior of the standalone of the plant. 



be completed. If Lp already satisfies the specification, £ is the desired control module 
C. Therefore, £ can be seen as a first approximation of C. 

In our example, the projection of the occurrence sequence {te}{tt rv _b, i 4 }{f 5 , if,} 
onto O yields the string {if,}, which is not a prefix of a word in L c - ( t a tb )*■ In such 
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cases, the aim is to add new net elements to £, thus defining causal dependencies between 
input and output transitions of £ to prohibit such undesired occurrence sequences. 

To summarize, the aim is to construct from £ a control module C which composed 
with V by the same composition mapping fl defining the composition of V and £ 
satisfies: Each occurrence sequence of the underlying signal net of C *n V respects the 
desired behavior in the sense that this occurrence sequence can be completed to another 
occurrence sequence of this underlying signal net whose projection onto (input and) 
output transitions of C, which replace event signal (inputs and) outputs of V, is a string 
of the desired behavior. 

We synthesize C in two steps. First, we define conditions of controllability of a 
regular sublanguage of L-p (analogously to [23]) and compute the maximally permissive 
controllable nonblocking subbehavior L n b sa f e of L-p satisfying L c as a finite automaton. 
This is done by manipulating regular languages in subsection 3.1. Second, we synthesize 
a signal net simulating the control structure given by this automaton and add this signal 
net to £. By this signal net the input and output transitions of £ are coordinated in such 
a way that L n i, sa f e is realized. 

3.1 The Behavior of the Controlled Plant 

We formulate our approach similar as it is done in classical supervisory control. The 
main technical differences to the classical supervisory control approach are due to the 
mentioned step semantics. Nevertheless, some algorithms of classical supervisory con- 
trol can at least be adapted to our framework. While omitting therefore most details of 
these algorithms, our paper remains self contained, i.e., it can be understood without 
previous knowledge of supervisory control. 

As mentioned in the last section, our aim is to compute a regular sublanguage L n b sa f e 
of Lp representing the maximally permissive controllable nonblocking subbehavior of 
Lp satisfying the specification. Roughly speaking, controllable means that L n b sa f e can 
be realized by a control. 

The computation of L n i, sa f e is done in several steps by manipulating regular lan- 
guages. For this we need a special projection operator Ay. Applying Ay to a language 
over an alphabet of the form 2 A means to project each word in this language onto 2 X ' ) . 
In [18,19] we showed that projection operations of the form Ay and pumping operations 
of the form Ay 1 preserve the regularity of languages. 

“Good" occurrence sequences. In a first step we delete all occurrence sequences w 
from Lp satisfying Xiut{ui) ^ L c , i.e. whose projections onto output transitions are not 
prefixes of L c {L c denotes the prefix closure of L c ). We call such occurrence sequences 
"bad" occurrence sequences and the remaining ones "good" occurrence sequences. 

For example, w = {t 3 }{tt ry _ a , t a } is a good occurrence sequence since 

/ ^/Ut(^ 7 ) = ^ L c , and V ^a} IS a 

bad occurrence sequence since A/u y(i>) = {t a }{t a } ^ L c . 

The set of all good occurrence sequences is denoted by L psa f e . It can formally be 
computed by 

Lpsafe ^/Ut(^ c ) ^ Lp , 
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Fig. 12. Automaton recognizing the language L paa f e . 



and is therefore regular. For our running example. Figure 12 shows a representation of 
Lpsafe as a finite automaton. 



Controllable occurrence sequences. In L psa f e there may exist good occurrence se- 
quences which can be extended within L-p to bad occurrence sequences. For example, 
the good occurrence sequence w = {te}{tt ry j>, t-i) can be extended by the step {f 5 , tb) 
to the bad occurrence sequence v = w{t$, tb) = {te}{tt ry _b, ti){t^ : tb). If this exten- 
sion is not controllable, i.e, contains no controllable transition, it can not be avoided by 
the control. In our example, once w is allowed, v can not be avoided: The step {t- n t;, } is 
not controllable, but can only be observed by the control. Therefore, we require L n b sa fe 
to satisfy the property 
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(1) What cannot be prevented, should be legal 

which we call the first condition of controllability. It corresponds to the classical notion 
of controllability in supervisory control. 

Good occurrence sequences which can be extended by uncontrollable steps to bad 
occurrence sequences are called dangerous occurrence sequences. They must be cut off 
at the last possibility of control, i.e. the last possible signal input (if there is one). In our 
example, after the step {^6 }, sending a signal input via occurrence of the transition t try _b 
should be forbidden, so w is cut after { t< : , } . By this, all dangerous occurrence sequences 
ending with a step containing an input and their futures are deleted from L psa f e . 

Due to unobservable transitions, there may remain good occurrence sequences which 
cannot be distinguished by the control from dangerous occurrence sequences deleted in 
the last computation step. For example, the control can not decide whether the occurrence 
sequence {^6 } has occurred or not since t(, is an unobservable transition. Therefore, 
forbidding the occurrence sequence { te}{tt ry _b , G} means to forbid also the occurrence 
sequence {t try _b}- This follows the rule 

(2) What cannot be distinguished, cannot call for different control actions, 

called the second condition of controllability. It corresponds to the notion of observability 
in supervisory control. 

In our example, since the signal input {U ry _b} is forbidden after the occurrence of 
{fg} according to the last computation step, it must also be forbidden from the initial 
marking (after the empty occurrence sequence). The cutting off of appropriate inputs can 
be represented by deleting corresponding edges in the automaton representing L psa f e , 
see Figure 13. 

Deleting all dangerous occurrence sequences and all occurrence sequences which 
are undistinguishable to a dangerous occurrence sequence L psa f e gives the language 

Lsafc 

L sa f e again can be expressed by a closed formula over regular languages, and is 
therefore regular. Moreover, it was proven to be the maximally permissive controllable 
sublanguage of Lp in [19]. For our running example. Figure 14 shows a representation 
of L sa f e as a finite automaton. 

In general, there can be an occurrence sequence w from L-p which contains no input 
transition and whose projection onto O is not a prefix of a string in L c . In this case we 
cannot control the plant in such a way that no undesired behavior will happen. Thus, 
only if there is no such sequence, the maximally permissive controllable sublanguage 
of Lp exists. 



Blocking occurrence sequences. By construction, every projection of an occurrence 
sequence in L sa f e onto O is a prefix of a string in L c . However, it might happen that 
there are occurrence sequences that cannot be completed within L sa f e to an occurrence 
sequence whose projection onto O is in L c , i.e. the desired behavior is blocked. We call 
such occurrence sequences blocking. 

In our example, L sa f e does not contain blocking occurrence sequences and there- 
fore is already the searched language L n b sa fe • Therefore, we illustrate the existence of 
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Fig. 13. Removing dangerous occurrence sequences and their future from the language L psa f e . 



blocking occurrence sequences by another example of the standalone of a module of 
a plant V given in Figure 15. The behavior L-p* of V' is given by the automaton in 
Figure 16. The automaton in Figure 17, also representing L-pi, is more appropriate to 
illustrate the procedure of deleting blocking occurrence sequences. 

The control specification is given again by the regular expression ( t a tb )*. All pro- 
jections of occurrence sequences of the standalone onto O = {t a . ti,} are prefixes of 
strings in L c . Thus, L sa f e = Lp> . However, the occurrence sequence 

f 1 5 ^ 7 5 3 5 ^3} {^6 5 ^85 5 7 ^ 9 7 ^ a} 



is blocking. 

Since every future of a blocking occurrence sequence is also blocking, we can delete 
blocking occurrence sequences by cutting them off at the last possible input (if there 
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Fig. 14. Automaton recognizing the language L ga f e . 



is one). The prefixes ending with these inputs are called real bad choices. In the above 
example, the last possible input is {U_ 3 , t 3 } and 

{t4}{ti_l,tl}{t5, h, t a }{ti_ 3 , t 3 } 

is the corresponding real bad choice (see Figure 17). 

Due to the second condition of controllability, such an input must be forbidden for all 
occurrence sequences which are undistinguishable to a real bad choice. Such occurrence 
sequences are called bad choices. In our example, 

1 ; ^3} 

is a bad choice undistinguishable to the previous real bad choice (see Figure 17). 

Deleting all bad choices and their futures from L sa f e possibly produces new blocking 
occurrence sequences. For example, after deleting the real bad choice 



{i4j-{fi_i, fi}{f5 , 17 5 t a }{ti_ 3 , t 3 } 
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Fig. 15. Standalone of a module. 



and its future produces the new blocking occurrence sequence 

Therefore we have to iterate this procedure (see Figure 17). 

To state the algorithm, we denote for any sublanguage K of L sa f e by Knocking 
the set of all blocking words of I\ and by Kbadchoice the corresponding bad choices 
in K. We showed in [19] that if K is regular then also Knocking and Kbadchoice are 
regular, since they can then be expressed by a closed formula over regular languages. 
The following algorithm deletes subsequently all blocking words from L sa f e : 

Input: Language K° = L sa f e , Integer i = 0. 

Step 1: 

Compute K l blocking . 

Step 2: 

If Kl locking contains at least one word without any input return ”L n t> sa f e does not 
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Fig. 16. Automaton representing the behavior of the standalone from Figure 15. 



ft 2 }.ft 3} ft il.ft 2 1 , ft 3} ft ibft 2} ft il.ft 2 }.ft 3} ft il.ft 2 1 , ft 3} ft il.ft 2 }.fti 3} 




Fig. 17. Automaton representing the behavior of the standalone from Figure 15 which splits the 
bad choices from other words. 



exist ” (because there is no possibility to avoid this word by control). 

If K i hocking is em P l y return K ' - 

Step 3: 

Compute Kl adchoice . 

Set K l+1 by removing all words of Kl adchoice and their future from K l . 

Set i = i + 1 . 

Goto Step 1. 

Starting with K° = L sa f e the algorithm iteratively deletes blocking occurrence 
sequences by cutting them off at the last possible inputs and by additionally deleting 
all undistinguishable occurrence sequences. This is done until either no new blocking 
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{ti 2 }.{ti 3} {ti i},ft 2 },{ti 3} fti), ft 2} 




Fig. 18. Automaton obtained by deleting edges representing bad choices from automaton in Fig- 
ure 17. 



occurrence sequences are produced or there is a blocking occurrence sequence without 
any input in the actually computed language (in which case no controllable language 
without blocking occurrence sequences exists). 

The algorithm returns a language if and only if the maximally permissive nonblocking 
controllable sublanguage exists, which we call L n b sa fe- A proof can be found in [19]. 

We briefly show that the algorithm always terminates. The main idea is to find a de- 
terministic finite automaton G recognizing L sa f e such that deleting words of K dadchoice 
and their future corresponds to deleting edges in G. A necessary and sufficient condi- 
tion for this is that the states of G distinguish words in KJ )adch(nce from words not in 
K'i 

badchoice’ 

In general, not each finite automaton A recognizing L sa f e satisfies this property. For 
example, the previously mentioned occurrence sequence 

{ti 1 , 1 1 }{f 5 ) 3 , 1 3 } 

is a bad choice. However, in the automaton representing L sa f e from Figure 16 the 
occurrence sequence 

1 1 f 1 }{f 5 > f a}{f6 5 5 1 fa } j 

which is no bad choice in K°, leads to the same state. In this case, deleting the corre- 
sponding edge would cut also nonblocking behavior off, i.e. it would cut too much. 

In [19] we showed that such an automaton G always exists by an effective construc- 
tion. 

Figure 17 shows an automaton recognizing the same behavior as the automaton in 
Figure 16 which distinguishes between bad choices. In the automaton of Figure 17 the 
bad choice (of the language K ° ) 



fl}{f5j fa}{f*_3> ^ 3 } 
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Fig. 19. Automaton obtained by deleting edges representing bad choices from automaton in Fig- 
ure 18. 



is now recognized by a different state as the occurrence sequence 

f 1 5 ? }{^6 5 f 5 1 f a} * 

The application of the algorithm to the automaton in Figure 1 7 is illustrated in Figures 1 8 
and 19. In the resulting automaton in Figure 19 the transition 1 4 , which can occur 
spontaneously, leads to a deadlock in the module. However, this is an "allowed" deadlock 
because the control specification "if a happens then b must happen too" is still satisfied. 

3.2 Synthesis of Control Modules 

In this subsection we show how to synthesize a control module C from the controllable 
subbehavior L. n b sa fe (see Figure 14) of Lp (see Figure 1 1) by adding new net elements 
to the environment module £ (see Figure 9). The composition of the resulting control 
module C with the plant module V has exactly the behavior L. n b sa fe , in the following 
sense: The projection of the behavior of this composed module onto the set I U O U T 
equals L n bsafe- 

To synthesize C, we consider the observable part of L n b sa f e , i.e. its projection 
A T{L. n b sa fe) onto input and output transitions. Figure 21 shows a possible automa- 
ton A recognizing \T(L n bsafe)- This automaton can be computed in two steps: First 
take the automaton recognizing L n b sa fe from Figure 14 and hide all transitions of T. 
The result is the nondeterministic e-automaton shown in Figure 20 (e is the empty word). 
This automaton can be transformed by a standard procedure into an equivalent deter- 
ministic automaton. The main idea for the construction of C is to simulate the control 
flow given by A by a signal net and to add this signal net to £. 

For an automaton with states drawn as filled circles and with labelled directed edges 
between states drawn as arrows with annotation, an edge leading from state s to state s' 
with label x is denoted by s -A s'. 

In our example, it is quite straightforward to compute a signal net which simulates 
A: Every state s becomes a place p s , and every edge s — > s' becomes a transition t * , . 
In case s ^ s', t ^ , has the preset {p s } and the postset {p s '}- In case s = s', t g ^ s , 
tests p s to be marked by a condition arc. Initially the place corresponding to the initial 
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Fig. 20. The nondeterministic e-automaton recognizing At ( L sa fe ) computed from the automaton 
recognizing L aa f e from Figure 14. 



state is marked. The procedure is illustrated in Figure 22. For convenience, we use a 
slightly simpler notation for the transitions. In case x = {tt ry _a} we write tto_try_a for 
t x . This illustrates the intended meaning of tto_try_a to send the input signal tryM to 
the plant. In case x = {t a } we write t from.a for t x , . This shows the intended meaning 
of tfrom-a to observe the output signal a sent from the plant. The labels x = {t try j,} 
and x = {tb} are treated analogously. Each state s of the automaton corresponds to the 
marking in the signal net where exactly p s is marked. 

When the resulting signal net is connected with the input and output transitions 
of C inherited from £ , the control module shown in Figure 23 is obtained. Using the 
connections between the plant and its environment £ , we get the controlled composed 
module shown in Figure 24. The control module formalizes the intuition of how to send 
inputs in order to observe prefixes of the desired output behavior ( t a tb )* : First the input 
tryM is sent at least once. It is sent as long as one observes the output a. After that it is 
no longer possible to send tryM. Then tryJ> is sent at least once. This input is sent as 
long as one observes the output b. Finally the behavior starts from the beginning. 

In general, the automaton A is more complicated because the arc labels are steps 
consisting of more than one transition. Therefore, the construction of C is more sophis- 
ticated. In [19] the construction of C for general automata A is presented. This paper 
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A T (L safe ): deterministic automata 




Fig. 21 . The deterministic automaton recognizing At ( L sa f e ) computed from the nondeterministic 
e-automaton from Figure 20. It is drawn in two different forms: The left Figure corresponds to 
the shape of the automaton recognizing L psa f e from Figure 12. The right Figure is convenient to 
deduce the signal net representing the control flow. 



Associated signal net 





Fig. 22. The signal net simulating the control flow given by the automaton shown above. 



contains a proof that the projection of the behavior of the composition of V and C onto 
the set I U O U T equals L n b sa f e . Since the general construction is very involved, we 
only give some examples for possible problems and their solutions. 

Basically, each state s of A can be modelled as a place p s , and each labelled edge 
s — } s' of A as an AliVU-synchronized transition t * , . In the case iCO, the transition 
t ^ , is intended to observe the step of outputs x. It is therefore synchronized by all 
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Fig. 23. The resulting control module given by the signal net from Figure 22 connected with the 
input and output transition from the environment. 




Fig. 24. The control module connected with the two plant modules. The composed module satisfies 
the specification in a minimal restrictive way. 

output transitions in the set {t a £ O \ a £ x}. If x contains signal inputs, the situation 
is more complicated. Each state is represented by a marking which consists in general 
of more than one place. 



Avoiding undesired conflicts caused by shared pre-places. Consider the automaton 
A shown in the left part and the signal net simulating A in the middle part of Figure 25 
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(a) 



false 



correct 



{Ol}/\(Ol,02> 
si m # s2 



(b) 




t s l2L2^ s2 






C t°3} > s1 t s . t°2.°3) > s 






Fig. 25. Part (a): Avoiding undesired conflicts caused by shared preplaces and checking exact 
markings. Part (b)\ Avoiding undesired conflicts caused by shared postplaces. 



(a). Since the transitions t {nl ~ t and t {ol , o2> share a pre-place, the occurrence of the 

s s 1 s -4- s2 

step of output signals {ol, o2} either synchronizes t {oi} or t ( „k„ 2 } ■ That means, 
in the marking corresponding to state s two steps are in conflict. Moreover, one of the 
steps (when t {ol} is synchronized) does not correspond to the control flow. 

s 1 — >■ sl 



The right part of Figure 25 (a) shows a signal net simulating A, where the mentioned 
conflict is avoided. To this end, a transition t e s mptv removing the token from the place 
p s is introduced. It is synchronized by both transitions t {o:L} and t {o i t02 > . Both 

s — y s 1 s 4_ s2 

transitions have empty preset and test the place p s to be marked via condition arcs. 
The occurrence of the step of output signals {ol, o2} now synchronizes both transitions 



t 



{ol} 



and t 



{ol 02 } 



Checking exact markings. In the last example, the occurrence of the step of output 
signals {ol, o2} produces the follower marking {/Vi • Ps‘ 2 } ■ Therefore, the marking cor- 
responding to the state s2 is {p s \ , p s 2 }. The occurrence of the step of output signals {ol} 
produces the follower marking {p s i}, which therefore is the marking corresponding to 
the state si. 

Since the transition t {o3} should only be enabled under the marking {p sl }. but 

S± — r S 1 

not under the marking {p s i,p S 2 }-, t { o3 } has to test the place p s 2 not to be marked. 

S 1 — ^ s' 
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Fig. 26. Part (a): Avoiding cycles of event arcs caused by signal inputs. Part (b): Distinguishing 
states by markings. 



This can be achieved by introducing a complementary place to p s 2 and to test this place 
to be marked. 



Avoiding undesired conflicts caused by shared post-places. Consider the automaton 
A shown in the left part and the signal net simulating A in the middle part of Figure 25 
(b). The occurrence of the step of output signals {o2, o3} in the marking corresponding 
to state s' synchronizes both transitions t {o3} and t, {o2i03} • Therefore, the marking 

s f — y s 1 s' — s2 

{psi,Ps 2 } corresponds to the state s2. Since the occurrence of the transition t {o2o3} 

s s 2 

must lead to the same marking {p sl , p s 2 }, the transitions t {o2o3} and t {olo2} share 
a post-place. Therefore, the occurrence of the step of output signals {ol,o2,o3} in 
the marking corresponding to state s either synchronizes t {o2t03 y or t { 01 , 02 } ■ That 
means, in the marking corresponding to state s two steps are in conflict. 

The right part of Figure 25 (b) shows a signal net simulating A where the mentioned 
conflict is avoided. For this, transitions resp. t{y l , which mark the places p s 1 resp. 
p s 2 , are introduced in a similar way as the transitions t e s mpt v which unmarks places. 



Avoiding cycles of event arcs caused by signal inputs. Consider the automaton A 
shown in the left part and the signal net simulating A in the middle part of Figure 26 
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(a). By the occurrence of transition t {i o} input i is sent to the plant. This produces a 

s - 4 - s2 

cycle of event arcs, since i possibly synchronizes the step of outputs {o}, which again 
synchronizes t {i>o} . 

The right part of Figure 26 (a) shows a signal net simulating A, where such cycles 
are avoided. For this inputs are modelled by additional transitions as shown. 



Distinguishing states by markings. Consider the automaton A given in the left part of 
Figure 26 (b). On the one hand, the occurrence of the step of output signals {ol, o2} in the 
marking {p s } synchronizes the transitions t {ol;02 } andf {oi} . Therefore, the follower 
marking is {p s i,p s 2 }. On the other hand, the occurrence of the step of output signals 
{ol, o2} in the marking {p s /} synchronizes the transitions t { 0lt02 > and t {oi} and 
the follower marking is also {p s \,p S 2 }. Therefore it corresponds to both states sl and 
s2. That means that the control does not distinguish between observable different states 
of the plant. 

This situation can be avoided if we modify the automaton A such that the states of 
A distinguish words according to their last character. More formally, we require x = y 
for all edges of the form s' -A s and s" A s. As long as this is not the case for a state 
s of A, i.e. x ^ y, one can split s into two copies, one for words ending with x and one 
for words ending with y. 



3.3 Alternative Techniques for Synthesis 

An approach that uses complete enumeration of the whole controlled behavior will ob- 
viously reach its limitation if the systems are large. It therefore makes sense to consider 
methods that use structural properties of the model instead. At the current state of re- 
search, a general approach for models without structural restrictions is unlikely. If one 
restricts, however, to models with simple structures, formal techniques for synthesis are 
possible. This holds in particular for pure Petri net models of the plant. 

Methods for controller or supervisor synthesis for Petri nets are well developed. 
This holds especially for specification in terms of forbidden states. A comprehensive 
review can he found in [13]. Synthesis methods for sequential specifications, however, 
are yet rather sparse. One significant contribution in this area is the work of Giua [7], 
who studied an alternative design to Ramadge and Wonhams monolithic supervisor. 
His method entails the Petri net modelling of subsystems and specifications, which 
are then combined through a "concurrent composition" operation. Then, a "refinement" 
step of the combined model ensures the non-blocking and controllable properties. In 
this case, the existence of the Petri net supervisor is guaranteed whenever the given 
Petri net subsystems are conservative, although additional structure may be needed in 
the refinement step. The main distinction to [7] in the method described in [21] is the 
connection of the plant and specification models, which is done through the condition and 
event signals of Signal nets. This is also the case when we consider systems where plant 
and controller interact with each other in a closed loop. So, the model of the admissible 
behavior will not be a classical Petri net but a Signal Petri net. The framework [21] can 
also be applied as long as the Petri net model of the plant is safe. 
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The scope of [21] is limited to solving the problem of preventing an uncontrollable 
event at a specific “controller state.” The method starts with a safe Petri net model of 
the system and a sequential specification that is modelled with a special state machine. 
A more general modelling framework for sequential specifications is currently under 
investigation, where a temporal logic formula can be mapped to a signal net model. 
An initial discussion is given in [20]. The main contribution in [21] can be described as 
follows: The condition and event signals of Signal nets are used to combine the plant and 
specification models. Then, the structure of this combined model allows to determine 
which controllable events need to be restricted by the controller, and at what states they 
need to be restricted in order to obtain the legal or admissible behavior of the system. 
Thus, a complete description of the state space is avoided, and control of the system is 
performed in a minimally restrictive way. 

Another issue that is currently under investigation is how to extend the method to 
reach some "target events" in the plant model. First results are presented in [22]. The 
major drawback, however, is that in general the set of all reachable markings are required 
to determine all feasible processes that lead to this target events. This means that even if 
a process exists that drives the plant model towards the target event, the process might 
be not feasible since it requires a marking that is not reachable from the initial marking. 



4 Conclusion 



In this paper we have illustrated methodologies for synthesis of control for DES with 
input and output structure. For input/output communication, we employ active signals 
which try to force events and passive signals which prohibit resp. enable event occur- 
rences. As a modelling formalism, we use modules of signal nets. Signal nets offer 
a direct way to model typical actuators behavior. Another advantage of such modules 
consists in supporting input/output structuring, modularity, and compositionality in an 
intuitive graphical way. 

Given a control specification in form of a regular language over output signals of 
the system, we showed how to automatically synthesize the control module. This forces 
the system to maximally permissive behavior preserving the control specification, in the 
sense that only sequences of outputs which respect the specification will be observed. 

In the paper we did not focus on complexity issues. It is known that the complexity 
of the supervisory control problem is PSPACE-hard in general, and sometimes even 
undecidable ([28], pp. 15 - 36). For efficient algorithms, the setting must be restricted in 
some way, for example by considering only very special classes of control specifications. 

We restricted our approach in several aspects: As a control specification, only se- 
quences of signal outputs were considered. Moreover, the synthesized controller changes 
at most one of its inputs to the plant at each moment. An extension of our methodology to 
control specifications including signal inputs and to controllers sending steps consisting 
of more than one signal input to the plant is a straightforward exercise. 

The presented approach considers only Petri nets on an elementary level. For complex 
industrial-size systems, these nets tend to be either very large or too abstract. In particular, 
data and time aspects cannot be modelled in a natural way. Therefore, we are working 
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on an extension of the control methodology for modules of signal nets with special 
high-level Petri net features. 
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Abstract Common engineering approaches and modelling approaches from 
software engineering are brought together. For the domain of process 
automation, i.e. product and plant automation, an implementation oriented 
approach for an object oriented software development for heterogeneous 
distributed systems is introduced. Model elements for control are added to 
UML as well as small-scale patterns for plant automation. Besides large-scale 
patterns are introduced as well as implementational models. The adoption of 
UML regarding applied diagrams and stereotypes for process automation will 
be introduced and structured components, an idiom for product automation 
software development, will be compared to other software engineering 
notations. 



1 Introduction 

Engineering approaches from the domain of engineering will be merged with 
advancements in modelling from software engineering. On the one hand process 
automation traditionally has focussed on implementation issues and on the other hand 
computer science has neglected the application domain to some extend by focussing 
on embedded systems in automotive and avionics. 

Software development in process automation (plant and product automation) has 
many deficiencies in procedures, notations and tool support. As a result, modern 
software engineering concepts and notations, like object oriented approaches or UML, 
are not wide spread in this field. Hence, drawbacks regarding start-up times, 
additional costs and low software quality are immense. This paper will derive a draft 
for an object oriented approach for this domain focussing on implementation aspects. 
This approach includes UML stereotypes. Besides, constraints for real time 
applications are necessary. For embedded systems, an implementation oriented 
approach will be discussed with restrictions of the object oriented constructs to meet 
constraints in storage and timing. 



2 Characteristics and Requirements of Embedded Systems 

The general requirements of embedded systems in process automation will be 
discussed. According to [1] embedded systems are automation (computer) systems, 
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which are integrated into a technical process. With this definition, every computer 
system ranging from tiny microcontroller units up to powerful multiprocessor servers 
is an embedded system as long it is integrated into a technical process. Examples for 
embedded systems in product automation are electric razors, washing machines or 
digitally programmed machine-tools as well as plant automation systems. 

In product and plant automation embedded systems are used, which differ from 
standard (industrial) PCs. It is examined what has to be considered when designing 
software for embedded systems. In [2] embedded systems are characterized by 

• the environment they work in, 

• the performance expected of them, and 

• the interfaces to the outside world. 

This article will only consider environment and performance of embedded systems, 
because they determine the constraints to software for these systems. An important 
aspect of the environment of an embedded system is the size and weight admitted to 
the system. For product automation system engineers, these can be the crucial issue to 
deal with. These factors are also limiting factors to software design, because they may 
result in only very few memory and very low computational performance of the 
device to use. Figure 1 shows the general purpose computing elements of embedded 
systems. Opposed to general purpose elements, there are also specialized computing 
elements (e.g. digital signal processors, mixed signal processors, or special system- 
on-chip designs), which are not covered by this paper. 



General-purpose computing 



Microprocessors 



General-purpose 




Highly integrated 




Single-chip 




Single-chip 


microprocessors 




microprocessors 




microcomputers 




microcontrollers 



Microcomputers 




Fig. 1 . General purpose computing elements of embedded systems 

An overview of requirements of process automation is listed in table 1 . The criteria 
can be structured regarding process requirements, automation system architecture, and 
project. In process automation, different kinds of processes are possible. In the 
following, a brief overview of those categories is given. A process automation system 
represents a type of process, e.g. batch, continuous, or discrete. Sometimes processes 
are composed of different process types. They are called hybrid, due to the fact, that 
they consist of different process kinds. These process types require different control 
strategies (closed and open loop control) and by that they require different modelling 
notation features, e.g. block diagrams or state charts. 

In addition overall requirements are real time requirements, including timers, the 
integration of I/O peripherals directly via a backplane bus system or a field bus, 
interrupts from the process and the necessity to describe the automation architecture 
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and the mapping from software to hardware. Multiprocessor systems like VMEbus 
may be included as well. 

Regarding an automation project, there are typically different engineers or 
technicians involved with different qualification levels and subjects. By that fact, the 
notation has to be easy to use to a certain level for process, mechanical, and electrical 
engineers as well as for technicians. A more visionary requirement is to support the 
entire life cycle with one consistent model, but appropriate notation for each phase of 
the project. 

Table 1 . Overview of requirements in process automation 



categories/ criteria 


fuuctiouality / notation aspects 


process 


batch (contimiotis) 


transfer functions, block diagrams, differential 
equation 




discrete 


status model, flow chart, continuous function 
chart, Petri net 




hybrid 


continuous and discrete process 


automation 


heterogeneous or 


distribution, communication, network / central 


system 


homogeneous 


unit 




different hardware platfonns 






different software platforms 






HMI, diagnostics, no screen 




time 


hard and soft real time; time and event 
controlled systems 




implementation 


IEC 61131-3 for PLC (embedded system). 
Proprietary for DCS; C, C++, Personal Java, 
Embedded Java, RT Java, Ada95 




level of automation 


in product, automation 100% 


project 


qualification 


easy Lo handle for engineers and technicians 


system life cycle 


top down design 

modularity, component base, object orientation 






Reusability 




tool support 


along entire life cycle 



The projects approach has been twofold in a differentiated manner. According to 
different tasks during the process of development it embraces different levels of 
abstraction. Concomitant it differs between plant and product automation. On one 
hand, there is the specification oriented approach, for which UML has been adapted 
by developing special stereotypes. On the other hand, there is an implementation 
oriented approach, which focuses on embedded systems constraints and derived 
requirements for an object oriented modelling and programming. Additionally 
modularity was aimed at [10]. 

Among object oriented programming languages the implementation oriented 
approach investigates structured programming languages using object oriented 
concepts. The reason for consideration of structured programming languages is due to 
the fact, that in embedded systems structured programming languages are wide 
spread. In the field of plant automation mainly languages of the IEC 61131-3 are used 
whereas C is very common in product automation. The programmable controllers and 
runtime environments of plant and product automation differ in the same way. For 
that in the following requirements and implementation are separately worked out. 
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3 Plant Automation 



3.1 Requirements 

The range of branches and technologies in plant automation varies in batch, discrete 
and continuous processing. Each branch has its own notations for the description of 
requirements, i.e. the documentation of given hardware and manufacturing processes. 
Despite these differences they have a lot of similarities. Very often the engineering of 
the automation system starts with the documentation of the plant construction and 
process engineering. Further on these information is used to extract sensors and 
actuators as inputs and outputs for the automation software and to create raw 
descriptions of the automation process. Finally they use the same type of automation 
devices. During the process of developing executable software the given information 
(user requirements) are detailed in terms of implementation requirements. The 
description of devices and behaviour changes from an abstract level to executable 
code. 

Today plant manufacturing industry requires standardized automation devices for 
automation systems, e.g. PLCs (Programmable Logic Controller), which are 
programmed in IEC 61131-3 [3] Therefore, the transfer of modelling results into IEC 
61131-3, which is standardised by the International Electrotechnical Commission 
(IEC) [16], is necessary. The IEC 61131-3 contains languages, which follow a 
function-oriented or procedural-imperative paradigm. The increasing use of these 
languages causes a growing dependency on the accepted standard, because existing 
implemented systems must be expanded and the developers are familiar with the 
practice of “accustomed” programming techniques. The accumulated expertise about 
home made modules allows a limited reuse and orientation. Without the knowledge of 
the experience from building modules, the acceptance of reusable modules is very low 
[17]. 

For special tasks such as safety related tasks or hard real time requirements 
additional automation devices may be used, e.g. process control computers with a real 
time operating system (RTOS). For hard real time systems specific requirements need 
to be realized. A list of implementation oriented real time requirements is depicted by 
table 2. Aspects of real time development like reactivity, multi-threading, time-based 
behaviour and real time environment need to be met. In the past efficient and 
machine-intimate but Gordian programming was necessary to fulfil these 
requirements. Actual controllers better their predecessors with a multiplicative 
computing performance. 

In plant automation, communication between several (embedded) systems is 
realized via different bus systems and in the following explained with the automation 
pyramid. In the level of field control buses like PROFIbus and Interbus [4] are 
deployed. Whereas the communication between and inside the level of process 
control, plant management, and enterprise administration normally is based on 
Ethernet and TCP/IP. For operation and maintenance, a PC-based human machine 
interface is used. By that fact the architecture of the automation system is 
heterogeneous. 
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Table 2. Real time requirements (functional /implementational model) [46] 



Useful Language Constructs 
for Real Time Programming 


Useful Description of 
Hardware Architecture 


task dispatch 


connection between 
peripheral device and 
technical process 


transition control between 
different states of a task/ state 
diagram 


Scheduling /EDF 


Process peripheral/ 
modelling of input/ output 


synchronisation of tasks 
/Semaphores, rendevous 


Architectural description of 
differentprocess computer 
units 


task activation / event 
handling (timer/ interrupts) 


communication between tasks 
(sent/receive events) 


connection between 
different computers/ 
network 



Another criterion for a successful project is to develop the automation system 
precise to customer requirements even if this functionality is mechanically under 
development. During design re-use of developed modules needs to be enabled. The 
test of this functionality prior to the start-up on plant site is next challenge. Therefore 
the specification, which should include testing requirements for soft- and hardware, is 
most important for each project. 

Plant automation is currently challenged by the demand of handling a growing 
complexity. New requirements push the boundary of former approaches for 
engineering hard- and software systems. New expansion space for a new, extended 
functionality has resulted from the fact that Moore’s law [11] is still valid [12] and 
performance of logic controllers is still rising. New field buses redefine the 
boundaries of distributed and centralized systems [13]. The power, given through 
these improvements stimulates the demand for implementing new functions. In plant 
automation huge application software and hardware for production and process 
engineering is developed often with much more than 3000 input / output points 
(process variables). These input / output points represent sensors and actuators. 

More than ever reuse is desired [table 1, 17, 18]. But reuse demands compliance of 
certain criteria. In [17] usability, suitability for adaptation and portability are 
mentioned. In [10, 18] modules are regarded differently, dependent on their grade of 
adjustment. This view differentiates between basic modules, which are implemented 
without changes of code and application modules which are derived from 
standardized templates. In both cases criteria like encapsulation and parameterisation 
target a reduced complexity of modules and systems to keep it clear and to raise the 
efficiency of changes [17, 18]. 

An efficient building of variants requires structures and methods which exceed the 
capabilities of function oriented or procedural-imperative languages defined in the 
IEC 61131-3. The prevalent practice of “copy, paste & modify” leads to scarcely 
manageable systems. Clear interfaces are highly demanded, but seldom found. The 
effort for design and change of complex requirements is very high, reliable prognoses 
about the completion of software systems are missing. All these occurrences are well 
known in conventional software development. Now automation systems have reached 
a grade of complexity which was first described as a software crisis [20, 21]. The 
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existence of powerful hardware allows applications with complex tasks. With an 
increasing performance of computing and communication, the classical software 
engineering has born methods and paradigms to profit from progress power with 
powerful software. It is expected, that the increase of computing power will continue 
[12, 22]. Thus the facilities of hardware will remain one step ahead the complexity 
which can be handled with structures and operations of state of the art software 
engineering. But the solutions, which are already found, extend the range of 
possibilities to handle complex tasks in a clear and structured way. One essential 
contribution is offered by the approaches of object oriented software development and 
programming. It is also convenient for the automation industry. 



3.2 Object Oriented Software Development 
3.2.1 Overview 

Object oriented concepts, notations and procedures have been developed to meet the 
requirements of complex software running on performant computer systems. The 
UML, as an object oriented notation, is no exception to that fact. Especially when it 
comes to code generation, nearly every UML code generation tool assumes a PC 
environment (e.g. integer size is supposed to be 32 bit) [7], However, UML's 
advantages, e.g. applicability across different development phases or degree of 
familiarity among developers as well as users, are also of value in embedded software 
engineering. To identify UML elements, that do (or do not) comply with 
microcontroller software constraints, an implementation driven approach has been 
chosen to assess the impact of object oriented elements on device resources. 

In the following other approaches should be introduced in comparison with this 
paper. ISILEIT [8] integrates SDL as an extended specification formalism into UML 
and realises code generation to Structured Text. The application is neither 
decentralised nor distributed and the real time requirements are compared with this 
report weak or soft. 

ODEMA [24] provides a UML-based concept without a special focus on 
distributed real-time systems or the domain of process automation. Braatz 
strengthened the necessity of automatic code generation for industrial automation as 
introduced in this paper. 

AUTOFOCUS [9] provides a concept of a component oriented architecture 
combined with a model driven, incremental development process. This approach is 
dissociated from UML as a complete set of diagram types. Instead the “AutoFocus 
modeling language & framework” has been created using parts of UML, UML-RT 
and other common notations. The development process and language support an 
incremental refinement combined with an increasing detail level of the model. Indeed 
the targeted industry (automotive) differs from the requirements of plant automation, 
especially the point of reuse is not worked out. 

UML 2.0 specifies with the Profile for Schedulability, Performance and Time 
Specification some useful constructs for real time systems. The UML 2.0 time model 
has no formal semantics as Berkenkotter et al. [43] analysed. Licht [44] proposed the 
integration of timed automata, which seems to be a very promising approach, 
regarding comprehensibility for engineers and formal specification. 
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Giotto is a programming language for embedded hard-real time control systems 
with periodic behaviour. “Giotto is a domain-specific high-level programming 
language: domain- specific, as it addresses embedded control applications; high-level, 
as it abstracts platformdependent implementation details... Giotto-based control 
systems separate the two concerns (reactivity vs. scheduling; timing vs. 
functionality)” [41]. The concepts for scheduling and timing aspects need to be 
evaluated for this project. Giotto worked also on distributed systems, but didn’t focus 
on process automation specific requirements or large scale software for plants. 

Ptomely [45] facilitates functional description by providing various models of 
computations and hence allowing different domains, but up to now process 
automation is not included. 

3.2.2 UML Diagram Types 

One of the working points in the research and development project DisPA is the 
analysis of existing UML diagram types concerning applicability in process 
automation [23]. The large number of different diagram types is sensed confusing and 
complicates the adjustment in UML. In particular, it is desirable for the acceptance in 
industry to choose an as small as possible number of diagram types. Especially for 
application in process automation [10, 18] it is necessary to proof the assignment of 
use case diagrams for description of requirements. In addition, the adoption of activity 
and collaboration diagrams concerning usage of redundant diagram types should be 
analysed. 

A first step is the evaluation of the experience of all DisPA project agents. As a 
result class, component, deployment, states, and sequence diagrams are chosen as 
adequate diagram types. Basis of this discussion is UML 1.4. In addition a 
combination of deployment and component diagram, which is offered in UML 2.0, is 
reasonable. Furthermore the timing diagram (UML 2.0), which is developed 
according timing diagrams in process automation, should be analysed, too. 

Current research investigates the evaluation of UML in software development with 
a typical automation process with electrical engineers in education [23]. A third 
aspect is the analysis of the agile UML method [25, 26]. Both evaluations are not 
complete, but seem to approve the application results of project agents. 

3.2.3 Designed UML Modelling Elements and Patterns 

The following chapters describe the new elements, which should complete the basis 
of the UML-PA subset (UML for Process Automation). These chapters include also 
their deduction from typical control automation notation. 

Designing UML-PA elements as a subset of the UML is oriented on the needs of 
users for intuitive programming complex distributed real-time systems. Regarding the 
requirements, which are listed at the beginning of this article, elements for modelling 
open and closed loop control, reconfiguration services (redundancy, diversity), time 
constraints and their reliability are needed. They should look like elements, which are 
used in automation engineering today. This is necessary for acceptance and 
consequently its adoption in industry. 

On this account we look at a one-to-one description in control engineering. Open 
loop control is the interaction of all output variables of a process by all input signals 
in a formal defined way. It is described with block diagrams. A block diagram is a 
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Command Control System 

Variable Actuating Output Output Output 




Fig. 2. Ideal block diagram of closed loop control 



graphical description of information flows of control system models. Each block is a 
graphic figure of a functional correlation. 

The special focus of the research and development project DisPA lies on the 
application oriented aspects. On this account UML-PA elements are developed to 
describe this typical control automation correctly in form and content. In the 
following a generic closed loop control is described with the UML-PA elements. 




Command Variable w 



Fig. 3. Corresponding use of UML-PA elements. The process is not part of the model. 

Based on these fundamentals a new stereotype named LoopControl is defined in 
UML. It is based on the stereotype Capsule [28]. All necessary attributes, operations, 
and a port are predefined. In addition the underlying state chart is predefined. It 
includes two sub-states {idle, active) as symbol for the activation of a loop control 
system. The real control takes place in the operation ControlF unction)). The 
command variable and the output variable can be written only via the defined port. 

Furthermore a closed loop control needs the definition of the actuating variable. 
Different controller types need specific data as parameter. One way is the definition 
of a new stereotype. This stereotype would include the transfer of constraints also like 
attributes, operations, and ports. Another possibility for realisation is the inheritance 
mechanism. The class ClosedLoopControl inherits from the class OpenLoopControl. 
ClosedLoopControl is the abstract super class for specialized controllers like P, PI, 
PID or PD. With it we have got first elements and we can combine them in the same 
way like blocks (figure 3). 

A flow control executes unavoidable stepwise. To continue into a next step a 
transition has to be fulfilled. These transitions can depend on time or signals from the 
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Fig. 4. State machine of the control cycle of the abstract class ClosedLoopControl 



process (figure 4), whereas the logic control is characterised by the allocation of the 
input signals to specific states of output signals. This mapping happens in the 
realisation of the abstract function ControIFunction( ). It is defined in the inherited 
controller classes. Figure 5 shows the state machine which implements the 
ControlF unction of a P-Controller. 



/ Result = -Vp*D+U / 



Fig. 5. P-Controller as an example for a ControlF unction 



The reconfiguration service can be used in new or already existing models to 
improve the functionality (i.e. safety) of target systems. A controller pattern consists 
usually of a sensor, an actuator and a controller device. The failure of one of the 
components results in failure of the entire control chain. This safety problem can be 
avoided by usage of redundant devices. However, the integration of redundant devices 
into an existing model is one of the main challenges, often the model structure and 
also already implemented code have to be changed. An inherited reconfiguration class 
is designed to solve this problem. It is a virtual representation of a defective device. 
Any deviation is corrected by an adjustment function (figure 6). 



Sensor 

IfSLeft : Sensor = NULL 
^>Right : Sensor = NULL 
^■DefectFlag : Boolean 
^>Hardware_Relations : Variant 



lGetValuet() : Double 
*SetDefectflag(SetFlag : Boolean) 
^GetNextRight() : Sensor 
^lnsertRight(Sr : Sensor) 
*ilnsertLeft(Sr : Sensor) 





Virtual_Sensor 


^Distance : Double 


♦Assign(Sr : Sensor) 
*SetDistance(NewDistance : Double) 
^Adjustment(lnputValue : Double) : Double 
■GetValueQ : Double 





Fig. 6. Virtual_Sensor as an inherited reconfiguration class 



As an example we suppose an additional sensor or an already existing is needed to 
improve the steadiness of a system, e.g. a sensor. In this case the reconfiguration class 
will simply replace the primary sensor device. The whole procedure is shown in 
figure 7. 
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Fig. 7. Sequence diagram: replacement of a defective sensor 



The configuration class Virtual_Sensor instantiates the physically existing device 
Sensor_2, but it corrects the measurement in a way, that the system’s handling of the 
substitute is identical to the original device. Therefore the reconfiguration class uses 
the mechanisms of inheritance and overriding. 



3.3 Implementation with IEC 61131-3 

Automation industry uses different platforms for process and product automation. 
Whereas the software engineering of controllers of embedded systems can participate 
in the advancements of conventional software development, which can be done using 
object oriented high level languages (mainly C++, EC++), embedded systems are 
only limited by available memory and computing speed. The available IEC 61131-3 
languages follow more traditional paradigms. Open and closed loop controls are 
realised through Functions (FUN), Function Blocks (FB) follow a proce- 
dural/imperative paradigm and object oriented concepts must be mapped. 

In plant automation existing software and the skills of specialists for plant 
commissioning still determine the software construction at implementation level. At 
this phase of development it is unavoidable to remain within established standards. 
Existing experience and the uncertainty of grave changes conserve the importance of 
the IEC 61131-3. With more distance to the placing into operation engineering is 
done on a more abstract level. 
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Some concepts target the mapping of a reduced UML to IEC languages [29]. 
Single extensions of PLC-toolsets, which are also function-oriented, allow extended 
modelling features, but they are isolated and don’t actually deliver concepts for re- 
use. 

Nevertheless we developed a toolset for automatic depiction (conversion) of a 
reduced UML model using an enlarged agile concept [27] to an implementation of 
IEC 61131-3 (TwinCAT based on CoDeSys [30]). TwinCAT was chosen as a wide 
spread IEC 61131-3 implementation for PCs and embedded systems, which refer to 
the standard. The diagrams for automatic conversion have been restricted to class 
diagrams, state charts, and system architecture diagrams, which is sufficient to model 
the automation of a lab model. 

The class diagram is used to realise the programme structure of the IEC 61131-3 
programme and by that the necessary Functions (FUN), Function Blocks (FB), and a 
Main Programme (PROG) are generated. The state charts are converted into 
Sequential Function Charts (SFC). This automatic conversion uses SFC and 
Structured Text (ST). The system architecture diagrams are used to design the 
hardware aspects, including automatic mapping of hardware addresses. The bi- 
directional mapping will not be adequate because this conversion uses IEC 61131-3 
without any enlargement. The most important result is the ability to include tasks and 
hardware aspects in this model [26], which is required (see table 1 and 2). 

3.3.1 Proposal of Object Oriented Enhancement 

The IEC 61131-3 languages are convenient to build block structures and this is the 
way, the agile concept can be mapped. A complete object oriented model requires 
more facilities, which are beneficial in automation industry to build variants (see 
requirement modularity, component base, reusability). Components, which will be 
reused need to match the following variations (figure 8). 

• reduction of a pattern 

• enhancement of a pattern 

• appendix of a functionality to a pattern 

• component should be appropriate for a pattern, i.e. through predetermined 
changes may be applied in another context 

It is important that the developer keeps the control whether a function is overridden 
[ 14] or not. Therefore the new keyword virtual initiates the overriding mechanism. 

The mechanisms of inheritance and overriding offer an opportunity for building 
variants with respect to the module characteristics encapsulation and 
parameterisation. Targeting plant automation these variation requirements on one 
hand, and respects the experience obtained by the familiar mode of operation on the 
other hand will be implemented using a design model. Therefore the object oriented 
structures and mechanisms of inheritance need to be added to the IEC 61131-3. A 
draft proposal for the languages of the IEC 61131-3 will be supplemented by 
enhancements. 

The syntax enhancements are keywords, which allow the definition of classes and 
controlling the mechanism of inheritance. Figure 9 shows this as an example for the 
IEC 61131-3 language ST (Structured Text [19]). The supplemented keyword CLASS 
is alike the existing keyword STRUCT, but it offers the encapsulation of declarations 
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Fig. 8. Target properties of variants (UML-syntax is used for model presentation) 



TYPE 

OneTankCont roller : CLASS 

VIRTUAL FUNCTION MaxReachend: BOOL 
END_FUNCTION; 

FUNCTION_BLOCK SetMax 
END_FUNC T I ON_BLOCK ; 

END_CLASS; 



TwoTankCont roller : CLASS (OneTankCont rolled 
OVERRIDE FUNCTION MaxReachend: BOOL 
END_FUNCTION; 

END_CLASS ; 

END_TYPE; 



Fig. 9. Proposal for enhancements of the language ST (Structured Text). (The enhancements 
are marked bold.) 



for operations and attributes. Other IEC 61131-3 languages can be enhanced in the 
same way. The mapping of the enhancements to the standards of IEC 61131-3 needs 
to be elaborated in a next step. 

3.3.2 Modelling of Hardware Aspects 

Prior research worked on a comparison of modelling techniques for distributed 
process control engineering and analysed UML and Idiomatic Control Language 
(ICL) regarding cognitive models and user acceptance (table 1 )[23] . The results of 
these approaches show the lack in an appropriate accepted modelling technique for 
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Fig. 10. System architecture as deployment diagram 



the design of plant automation integrating hardware and software as well as 
architectural aspects (table 2) [10]. 

For modelling hardware aspects UML provides the deployment diagram. For 
embedded systems usually standard UML diagrams are used, e.g. class diagrams for 
modelling the system and its environment. In a pragmatic manner some constructs, 
which are well known from SA/RT are used as architecture interconnection diagram, 
architecture flow diagram or architectural dictionary, which map the components of 
the model to architectural components. This idea is integrated into agile UML [27] 
without any formal or semi-formal basis. 

Based on this idea, the system architecture could be modelled as an enlargement of 
the component diagram using the ARTiS AN tool Real Time Studio [3 1 ] and applying 
a top-down design [25], To model I/O peripherals, subsystems and interfaces are 
used. Stereotypes for different subsystems are defined, e.g. bus coupler, bus I/O, 
actuator/sensor, etc. Actuators and sensors may be arranged as a subsystem and are 
modelled as a subsystem with interfaces. This is realised with the definition of a new 
stereotype IO-Entity. 

This stereotype can refer to an attribute of a class, which is used to implement the 
hardware address. The stereotype of this attribute is called hardware address, which 
is the real physical address on the field bus or the I/O card of a PLC. 

For this reason, sensors and actuators are connected with real physical hardware 
address. This is one prerequisite to close the gap between hardware and software 
engineering. 

The engineering of I/O peripherals, i.e. the acquisition of the real hardware address 
into the programming environment, will be realized automatically on this basis. 
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4 Product Automation 



4.1 Product Automation Versus Plant Automation 

While product automation is strongly demarcated from plant automation, there are 
also some commonalities, which form a connection between software modelling / 
implementation in both domains. 

In product automation, microprocessors are mainly used as computing devices, as 
opposed to plant automation, where PCs may be used. Nevertheless, also in plant 
automation microprocessors are used e.g. in smart sensors / actuators that are 
connected to field bus systems. That is why software engineering methods that target 
embedded devices in product automation are also imperative for plant automation 
software engineering. 



4.2 Specific Requirements 

Since microprocessors are only one element of embedded systems in product 
automation, we will focus rather on microcomputers than on "pure" microprocessors. 
Single chip microcomputers include the following core elements: Microprocessor, 
memory, address decoder and external bus interface. Additional elements include 
(real-time) clock, hardware timers, communication controllers and I/O peripherals. 

The main difference between single-chip microcomputers and single-chip 
microcontrollers are the additions to I/O interfacing at microcontrollers, which are 
usually aiming at the embedded control market. Possible additions include field bus 
(often CAN) network interfacing, analogue-to-digital converters (ADCs), digital-to- 
analogue converters (DACs), digital input and output channels. However, this 
distinction is blurred [2], because also single-chip microcomputers may include above 
mentioned additions. An example would be the Renesas M16C/6N group of single- 
chip microcomputers [5]. Embedded systems are often equated with single-chip 
microcomputers / microcontrollers. Hence, the term "embedded system" will denote a 
single-chip microcomputer / microcontroller in this article. 

The performance of embedded systems is varying strongly. While in PC systems 
32 bit bus width is common (currently migrating to 64 bit), in the embedded world, 
there exist bus widths from 4 bit over 8 bit and 16 bit up to 32 bit. While 4 and 8 bit 
microcontrollers usually have to be programmed in assembly language, their software 
is not complex enough to require object oriented development methods. 16 or 32 bit 
devices can be programmed in high-level languages, e.g. C [6], These devices enable 
the use of more complex software, so that object oriented methods may become 
necessary. In product automation, 16 bit devices are usually sufficient, so they are to 
be preferred to 32 bit systems due to their lower price. Hence, this chapter focuses on 
16 bit microcontroller systems. 

Compared to standard PCs, 16 bit microcontrollers have very little memory: 
usually 5 - 30 fa'/obytes as opposed to - 512 megabytes. Additionally, their 
computational performance is by factor 100- 1000 lower than that of PCs, due to 
their bus width and lower clock frequency, approx. 10-30 megahertz (PCs: 1-3 
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gigahertz). To work under such conditions, microcontroller software has to be an 
order of magnitudes smaller in size and more efficient than PC software. 



4.3 C++ in Product Automation 

4.3.1 Introduction 

The most common high level language for embedded system programming is C. The 
object oriented language C++ [32] emanated from C, being enhanced with object 
oriented constructs. While C++ permits the programmer a high degree of freedom 
concerning object oriented implementation, i.e. from using no object orientation at all 
to using "unsafe" techniques like multiple inheritance, everything is allowed. 
Therefore, a consortium of Japanese microcontroller manufacturers has defined a 
subset of C++, which meets the terms of embedded devices: Embedded C++ (EC++) 
[33], 

EC++ strives to fulfil the following requirements of embedded systems design: 

• Avoiding excessive memory consumption 

• Taking care not to produce unpredictable responses 

• Making code ROMable 

• Easy applicability 

Therefore, some object oriented features have been omitted from the EC++ 
specification: 

• Software design with multiple inheritance is difficult even for experienced 
developers. Structural diagrams using multiple inheritance tend to be less readable, 
the software tends to be less reusable and less maintainable. To avoid the 
aforementioned drawbacks, multiple inheritance has been omitted from the EC++ 
specification. 

• Generic classes (template classes) may cause unexpected growth of code size if 
used carelessly. Since program size is critical for embedded systems applications 
and efficient use of generic elements requires a high level of experience, this 
feature has been left out from the EC++ specification. 

• Namespaces correspond closely with the UML package concept. Due to the limited 
memory of embedded systems, the size of embedded applications cannot be very 
large. So, names will seldom, if ever, come into conflict and namespaces are not 
needed for embedded software development. 

• Runtime type identification (RTTI) will result in program size overhead, because 
the compiler has to add type information for polymorphic classes. Additionally, 
RTTI is only of advantage, if polymorphism is heavily used. Since program size is 
critical and complexity is too low to require intensive use polymorphism, RTTI is 
not present in EC++. 

• Exceptions are useful for dealing with errors, but it is difficult to estimate time 
between exception occurrence and exception handler start. It is as well difficult to 
determine memory consumption for exception handling. Thus, exceptions are not 
present in EC++. 




316 



K. Fischer et. al 



Comprising, it can be stated that some features of object orientation should be left 
out to develop software for embedded devices. When it comes to the definition of a 
UML based notation for modelling embedded software, this should be regarded. 
Hence, multiple inheritance, generics, namespaces (provided by UML packages) 
(figure 11), and heavy use of polymorphism ought to be omitted from that definition. 
Exceptions are no object oriented concept per se, but most object oriented languages 
include exceptions and a catch/throw-mechanism. Additionally, some UML tools 
allow the specification of exceptions [34]. 




I Parameter 

GenericClass I 



Namespace 



Fig. 11. Multiple inheritance, parameterised class, package with namespace in UML notation 



4.3.2 Structured Programming Languages for Product Automation 

While object oriented development methods are considered very sceptical by most 
embedded software developers, they could hardly prevail against traditional, 
structured methods. Even low footprint 00 languages like Embedded C++ are mainly 
targeting 32 bit MCU applications [33], being still too memory consuming for 16 bit 
devices. Another approach to access the advantages of object orientation and 
according notations like the UML are Structured Components [35]. Structured 
Components are a programming idiom that uses a structured programming language 
(here: C) to develop flyweight components for embedded systems. Components 
generally have 8 attributes: functional closeness, structural independence, uniqueness, 
adaptability, ability of combination, concurrency, immutability (by a third party), and 
openness. Some of this attributes correspond with 00 features (e. g. functional 
closeness). The difference to object orientation manifests mainly in the improved 
reusability of components compared to OO structures. 

As well as object orientation, component orientation is hardly used in embedded 
systems development, because "traditional" component models (e.g. COM, CORBA) 
require overhead due to middleware that is needed to employ component 
technologies. Structured Components do not have need of middleware and they can 
be modelled using OO notations. This chapter evaluates Structured Components 
modelling in order to find additional OO/UML features that do (or do not) comply 
with embedded systems constraints. 

Structured Components do strictly distinguish between internal states and 
interfaces that display functionality to the outside world. Three parts can be 
differentiated: the structured component itself (active and passive), service interfaces 
and event interfaces, which can be modelled using UML class diagrams. The detailed 
principle of function of Structured Components can be found in [36]. The interesting 
fact is, that there are some modelling elements allowed, that are considered 
inappropriate for embedded software development by EC++: multiple inheritance and 
parameterisation (figure 12). 
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Fig. 12. Structured Components Structure 



However, it must be noticed, that the Structured Component principle does also 
comprise of an idiom, how a diagram is to be converted into source code. This idiom 
is tailored to the needs of embedded systems: 

• Multiple inheritance is allowed as long as it is only realisation, i. e. one 
component may possess multiple interfaces. This technique is very close to 
traditional C programming for embedded systems, where functions are often 
called not “directly” but via function pointers. These function pointers are 
registered with an application, which later employs them to call a function. 
Structured Components interfaces bundle groups of functions and allow 
registration of multiple functions with one call as well as dynamic exchange of 
the actual implementation. 

• Parameterisation is only possible with constant values, e.g. the maximum 
amount of memory a component may possess. OO-like parameterisation, 
where the parameter usually consists of a type of a variable, is prohibited. 

Structured Components are a powerful method to develop embedded software. 
Structural independence and adaptability make them reusable without the need of 
manually altering code inside of a component (copy, paste and modify). Their 
capability of concurrency (active components) is significant for embedded steering 
and control tasks. The ability of combination and the differentiation of interfaces and 
implementation allow dynamic exchange of the actual functionality of a component, 
e.g. to adapt to different hardware parts. This dynamic exchange enables also dynamic 
reloading of Structured Components into embedded devices. Since Structured 
Components can be written in C, they are both lightweight and efficient. 







318 



K. Fischer et. al 



4.3.3 Additional Possibilities 

There exist some other technologies (usually programming languages bundled with 
class libraries), which claim the ability of embedded software development, e. g. 
Java 2 Micro Edition or .NET Compact Framework. Most of these technologies target 
systems that feature certain requirements concerning computational performance and 
memory. Examples would be mobile phones or personal digital assistants. Thus, none 
of these technologies is suited for the class of embedded devices that is mostly used in 
product automation. 



5 Conclusion 

Looking at the process automation approach at first we find the successful 
development of notation elements for open and closed loop control, interlocking and 
redundant hardware aspects, which are part of characteristic aspects of embedded 
systems. We designed intuitive applicable elements on the basis of typical modelling 
constructs in control automation. In addition we show a possibility to bridge the gap 
between the function oriented paradigm used in plant automation industry (IEC 
61131-3) and the object oriented approach, which is an important aspect for adoption 
in industry. This aspect is not at least shown by the usage of reusability. 

Regarding the product automation approach the comparison of EC++ and the 
Structured Components displays, that there is no UML element that is per se suited or 
not suited for embedded software development. While parameterised classes are 
considered ineligible for EC++ development, they are welcome for Structured 
Component implementers. The crucial issue is neither the modelling element nor the 
object oriented concept modelled by the very element, but rather how efficient it is 
transformed into source code. Willert [38] states, that experienced embedded 
developers instantly know, how a high level programming language statement is 
compiled into machine language by the respective compiler. According to that 
knowledge, they choose constructs that compile efficiently for the target platform. 
This exactly is the task of UML design tools, to define the mapping rules from model 
to code according to the target system. Structured Components are a very good 
starting point, because they incorporate attributes of object orientation (which allows 
UML modelling), but are implemented using a structured language (which render 
possible efficiency). 

The discussed embedded software engineering methods are relevant to both 
product and plant software development. They can be used to model traditional 
product automation software as well as control or (field bus) connectivity software 
that is used in plant automation. Hence, the presented “embedded capable” UML 
elements should be used to model the depicted control patterns for plant automation. 

At this point the presented parts of UML-PA may look fragmental, but the 
complete UML-PA will bridge the gap between process automation and computer 
science. The composition of these parts is the result of the detailed requirements 
analysis, which was made already in the forefront of the UML-PA elements’ 
development. These requirements based on one hand on different interviews with 
software developer and user [10, 18] and on the other hand on the evaluation of 
presently offered UML tools [37, 39]. 
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6 Outlook 

While exemplary artefacts of embedded software have been developed using UML- 
PA and Structured Components, a “real world” example of appliance is still to be 
elaborated. Therefore, two case studies have been designed to serve as evaluation 
environment for the embedded software designed with UML-PA. The practicability of 
UML-PA, as well as the code size and the required computational performance of the 
software will be evaluated. 

As one case study is the demonstrator “single-track level crossing in radio based 
operation” [47] will be used. This demonstrator contains multiple devices with 
comparable functionality. This comparable functionality should be dealt with one 
single Structured Component type that is accordingly parameterised. One component 
type driving several different systems is a strong indicator for the reusability of 
software components, which have been developed with UML-PA. 

The other case study ,the demonstrator “continuous hydraulic press”, represents a 
process from timber industry: a plant which produces fibreboards. The press has got 
most restrictive requirements. Time critical closed loop control has to be combined 
with open loop control and switching to other control loops. This demonstrator is built 
of several single board computers (SBC) with a real-time operating system connected 
via a fieldbus. 

To meet real time criteria of technical processes, UML-PA has to support real time 
concepts. The OSEK 1 [48] guidelines have been established as a standard for real-time 
operation systems in the embedded domain. The OSEK Implementation Language 
(OIL) allows specifying real-time aspects. So it is obvious to introduce OIL constructs 
to UML-PA. 

Outside the scope of this project, but never the less an interesting enhancement of 
software, that is designed using UML-PA and implemented with Structured 
Components, are the aspects dynamic reloading during runtime, automatic (re-) 
configuration and decoupling of software fragments. Both UML-PA and Structured 
Components offer promising fundaments to realise such features, due to their 
supported characteristics concurrency, structural independence, and immutability (by 
a third party). The challenge to realise the above mentioned abilities is the required 
communication infrastructure of the software components. Today, this is usually 
accomplished by communication interfaces, which are also supported by UML-PA. 
Unfortunately, these interfaces must be known and implemented at compile time, 
determining the communication structure is static, i.e. it must be known, which 
component communicates with which other components. Since automation systems 
usually have not only a high degree of complexity, but also a very long life span (may 
be up to 30 years), changes while prosecuting the system are difficult at best. 
Software that supports such dynamic behaviour could be developed using UML-PA 
and Structured Components as a basis, but this software would need additional 
features like the ability to negotiate with other parties and to dynamically adapt to 
given needs. Therefore, continuative methods for software development are 
necessary. 



1 Open systems and the corresponding interfaces for automotive electronics 
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The subject area ‘Charts’ groups together those projects that study visual spec- 
ification formalisms or charts. Visual formalisms promise to support the use of 
formal methods in the engineering process of (embedded) software systems by 
being high-level languages that are equipped with a formal semantics in the 
elementary formalisms like temporal logic or finite state machines. 

The use of chart languages has a long tradition in the domain of systems en- 
gineering as a means to support the intuition of the designer and thereby to allow 
to cope with the complexity of systems under design. For example, the domain 
of programmable logic controllers (PLC’s) has a long history of graphical “pro- 
gramming languages” , from ladder diagrams to sequential function charts [1] , in 
the domain of reactive systems Harel’s Stateclrarts [2] find widespread use, and 
also object-oriented analysis and design are accompanied by multiple visual for- 
malisms, some of which finally merged into the Unified Modeling Language [3]. 

The aim of the DFG focus area program is the integration of software specifi- 
cation techniques for the application in the engineering sciences. As just pointed 
out, many specification techniques are visual formalisms hence the study of the 
exact formal semantics of existing charts languages and their integration are a 
prominent part of the focus area program. 

The chart languages considered in the subject area comprise Statecharts in 
the UML semantics [4] and also the classical Statemate semantics [5] , Sequential 
Function Charts (SFC) [6], and Live Sequence Charts [7]. Hence the range is 
from languages that describe models of a system under design (Statemate Stat- 
echarts, UML, SFC’s) to more declarative languages that specify behavioural 
requirements (LSC’s [8]). 

A prime topic of the subject area is the definition of a rigorous semantics of 
the considered charts languages. Without a formal semantics, the use of visual 
formalisms is merely illustrative and hence lacks the advantages of formal meth- 
ods: the possibility to unambiguously determine the meaning of a document and 
the possibility to apply automatic or semi-automatic formal verification technol- 
ogy. Verification in the sense that a model is checked for satisfying a specification, 
that is, it is proven that the model satisfies the specification, allows to detect 
errors in a design as early in the development process as possible and hence 
reduces costs and efforts to revise the design. For these reasons the verification 
of charts is the other prime topic of the subject area. 
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The results presented in the following articles range from a semantics of UML 
Statecharts as used by the design tool Rhapsody [4], over a formal semantics for 
Sequential Function Charts that allows to capture semantical deviations between 
commercial tools supporting SFC’s as a standardised “graphical programming 
language” for PLC’s [6], a formal semantics of the specification language of Live 
Sequence Charts [7], to an approach for formal verification of Statecharts in an 
interactive way using a theorem-prover [5]. 

The invited contribution by D. Harel and H. Kugler [4] provides an in-depth 
discussion of the semantics of Statecharts as implemented by the UML tool 
Rhapsody that was among the first executable semantics for object-oriented 
Statecharts. 

The main difference to classical Statemate Statecharts, where events, i.e. 
stimuli issued and processed, are only visible for a single step, lies in the intro- 
duction of event queues. In the UML semantics, events are stored in an event 
queue and processed one after another. 

The contribution of project ForMoSA (W. Reif, G. Schellhorn, A. Thums, 
F. Ortmeier (Augsburg)) [5] reports on a theorem-proving based procedure to 
formally verify Statecharts (in the Statemate semantics) against properties in 
Interval Temporal Logic in order to overcome the limitation finite-state methods 
pose on the data domains. That is, the goal is to be able to reason about models 
without imposing the assumption that all domains are finite. The proof strategy 
is symbolic execution for which the proof conditions are presented. 

This provides the basis for the aims of ForMoSA concerning formal fault tree 
analysis, a combination of formal models with safety analysis techiques from 
engineering. 

The topic of the project USE (Damm, J. Klose, B. Westphal, M. Brill (Ol- 
denburg)) is the assessment of the application of Live Sequence Charts (LSC’s) 
as a specification language for communication between sub-systems. This com- 
prises the development of a complete formal semantics with the aim to provide 
developers with tools for automatic formal verification of LSC specifications 
against system models. In the contribution to the subject area ‘’Charts” they 
provide the formal semantics of LSC’s in terms of timed automata [7]. 

Sequential Function Charts (SFC’s) are a graphical formalism for writing 
concurrent control programs, in particular targeted on PLC automata. The syn- 
tax of SFC’s is given by an international standard yet a survey of the semantics 
implemented by a number of programming tools provided by PLC suppliers 
unveiled significantly different interpretations of the standard. 

The associated project SFC-Check (Y. Laklmech, W. P. de Roever, B. Lu- 
koschus, R. Huuck (Kiel), S. Engell, S. Kowalewski, N. Bauer (Dortmund)) con- 
tributes a formal semantics of SFC’s that is as flexible to formally capture the 
complete range of semantical deviations found in the survey [6] . This semantics 
in particular provides the basis to, for example, automatically check SFC’s for 
different notions of well-formedness. 




324 W. Damm and B. Westphal 



References 

1. International Electronical Commission: Programmable controllers - programming 
languages, IEC 61131-3 (1998) 

2. Harel, D.: Statecharts: A visual formalism for complex systems. Science of Computer 
Programming 8 (1987) 231-274 

3. OMG: Unified Modeling Language Specification, ad/01-09-67 (2001) 

4. Harel, D., Kugler, H.: The Rhapsody semantics of statecharts (or, on the executable 
core of the UML). In: this volume. (2004) 

5. Tliums, A., Schellhorn, G., Ortmeier, F., Reif, W.: Interactive verification of state- 
charts. In: this volume. (2004) 

6. Bauer, N., Huuck, R., Lukoschus, B., Engell, S.: A unifying semantics for sequential 
function charts. In: this volume. (2004) 

7. Brill, M., Damm, W., Klose, J., Westphal, B., Wittke, H.: Live Sequence Charts. 
In: this volume. (2004) 

8. Damm, W., Harel, D.: LSCs: Breathing life into message sequence charts. Formal 
Methods in System Design 19 (2001) 45-80 




The Rhapsody Semantics of Statecharts 

(or, On the Executable Core of the UML)* 

(Preliminary Version) 



David Harel and Hillel Kugler 

Department of Computer Science and Applied Mathematics 
The Weizmann Institute of Science, Rehovot, Israel 

{dharel , kugler}@wisdom . weizmann .ac.il 



Abstract. We describe the semantics of statecharts as implemented in 
the current version of the Rhapsody tool. In its original 1996 version this 
was among the first executable semantics for object-oriented statecharts, 
and many of its fundamentals have been adopted in the Unified Modeling 
Language (UML). Due to the special challenges of object-oriented behav- 
ior, the semantics of statecharts in Rhapsody differs from the original 
semantics of statecharts in Statemate. Two of the main differences are: 
(i) in Rhapsody, changes made in a given step are to take effect in the 
current step and not in the next step; (ii) in Rhapsody, a step can take 
more than zero time. This paper constitutes the first description of the 
executable semantics of Rhapsody, highlighting the differences from the 
Statemate semantics and making an effort to explain the issues clearly 
but rigorously, including the motivation for some of the design decisions 
taken. 



1 Introduction 

In this paper we describe the semantics of statecharts as implemented in the 
Rhapsody tool. Some early work on incorporating statecharts into an object- 
oriented framework appears in [11,1,12], However, the detailed basis for a seman- 
tically solid 00 version of the language of statecharts first appeared in [5]. Two 
consequences of [5] were (i) the development of the Rhapsody tool to support 
object-oriented statecharts, and (ii) the essential adoption by the UML develop- 
ers of its underlying semantics. As a result, Rhapsody [9] can be viewed as the 
tool that captures the executable kernel of the UML [13]. 

This having been said, and despite extensive UML documentation, it is also 
commonly known that there has never been a responsibly detailed description of 
the executable semantics of the 00 statecharts language of [5], as captured by 

* This research was supported in part by the John von Neumann Minerva Center 
for the Verification of Reactive Systems and by the European Commission project 
OMEGA (IST-2001-33522). 
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Rhapsody. This we take upon ourselves here, making an effort to explain the is- 
sues clearly, including the motivation for some of the design decisions taken. We 
focus on the differences between the object-oriented nature of Rhapsody com- 
pared to the original non-00 stateclrarts in Statemate. The general spirit and 
structure of this paper are similar to the paper that described the Statemate 
semantics [6], and occasionally we even borrow some of the phrases from there. 
This is done not out of laziness, but to allow readers familiar with statecharts 
to easily focus on the novel aspects in the new approach. Still, the paper is self- 
contained, and so is accessible to readers who are not familiar with Statemate 
semantics or with [6]. 

The current version of the semantics is a result of much experience gained 
by users of the Rhapsody tool over the years, which led to modifications and 
adjustments. Rhapsody executable models can be run in different modes of op- 
eration: regular mode, trace mode or animation mode. In the trace and animation 
modes the user can test the model’s behavior by simulating the environment. Af- 
ter each step, the user can generate events and invoke triggered operations that 
will influence the run of the system. In trace mode, textual information about 
the system behavior is displayed, while in animation mode a visual graphical 
representation is displayed showing how the active configuration of each object’s 
stateclrart changes, by highlighting states entered and transitions taken. The 
animator can also show inter-object behavior, by creating animated message 
sequence charts that show graphically how messages are sent between objects 
during runtime. These can then be compared with previously prepared sequence 
charts that capture requirements on behavior. There are many interesting issues 
related to the animation of executable models, but they are beyond the scope 
of this paper. An important fact that should be stressed is that in contrast to 
Statemate, the trace and animation modes in Rhapsody use code generated 
by Rhapsody with additional instrumentation, so that the behavior of the sys- 
tem in these modes is the same as that of the actual production code. This is one 
of the basic principles that gives added power to executable object modeling. 

2 The Basics 

An object-oriented system is composed of classes. A stateclrart describes the 
modal behavior of the class, that is how it reacts to messages it receives by defin- 
ing the actions taken and the new mode entered. A class can have an associated 
stateclrart describing its behavior. These classes are called reactive classes. 
Simple classes that are data driven do not necessarily have statecharts. During 
runtime there can exist many objects of the same class, called instances, and 
each can be in a different active configuration - a set of states in which the 
system resides. Thus, a new stateclrart is “born” for each new instance of the 
class, and it runs independently of the others. 

The stateclrart itself is similar to the original description in [4], and to that 
of Statemate [6,7], in that there are three types of states, OR-states, and- 
states and basic states. The OR-states have substates related to each other 
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by “exclusive or”, AND-states have orthogonal components that are related by 
“and”, while basic states have no substates, and are the lowest in the state 
hierarchy. Fig. 1 shows the hierarchy and the three types of states that can be 
used in a statechart. States S, B , C, D are OR-states, state A is an AND-state and 
states B 1, B 2, Cl, C2, D 1, D 2, E are basic states. When building a statechart 
in Rhapsody an additional state is created implicitly, the root state, which is 
the highest in the hierarchy, in this case the root state has state S' as a substate. 



f s 




A 



r e 



\ > 
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Fig. 1. A small hierarchy of states 



The active configuration is a maximal set of states that the system can be in 
simultaneously, including the root state, exactly one substate for each OR-state 
contained, all substates for each AND-state contained and no additional states. 
An example of an active configuration of the statechart in Fig. 1 is : 

{Bl, B, Cl, C, D2, D, A, S, root}. 

The general syntax of an expression labelling a transition in a statechart is 
“m[c]/a” where m is the message that triggers the transition, c is a condition 
that guards the transition from being taken unless it is true when m occurs, and 
a is an action that is carried out if and when the transition is taken. All of these 
parts are optional. 

In Rhapsody, there is a single trigger, which can be an event or a triggered 
operation. Events mean asynchronous communication and triggered operations 
mean synchronous communication. This issue is discussed in greater length in a 
separate section. It is also possible to have a transition without a trigger, called 
a null transition. Another kind of message that is used in Rhapsody is a 
primitive operation, which corresponds to an invocation of a method call in 
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the underlying programming language. A primitive operation cannot be used as 
the trigger of a transition in a statechart, but it can be used in the action part. 
A trigger can also be a special event timeout, abbreviated tm(t), where t is the 
time in milliseconds until the event occurs (measured from the time the relevant 
source state was entered). In Rhapsody, the guard and action are written in 
the implementation language 1 and in contrast to Statemate there is no special 
action language. This is a practical design decision, but it should be emphasized 
that in principle it would be no problem to incorporate such a language. In 
fact, once the community agrees upon an abstract action language, this could 
be integrated into the Rhapsody tool semantics in a natural way. 

Besides actions that appear along transitions, they can also appear associ- 
ated with the entrance to (Entry action) or exit from (Exit action) a state 
(any state, on any level). Like actions on transitions, these too are written in the 
implementation language. Actions associated with the entrance to a state S are 
executed in the step in which S is entered, as if they appear on the transition 
leading into S. Similarly, actions associated with the exit from S are executed in 
the step in which S is exited, as if they appear on the transition exiting from S. 

A state can have static reactions (SRs), which have the same format as 
transition labels, i.e. , “m[c]/a”, and again the guard and action are written in 
the implementation language. Consider the statechart appearing in Fig. 2 (a). 
State W is associated with a static reaction, as noted by the > symbol attached 
to its name in the statechart. The actual static reaction / /act() is shown in the 
state menu at the bottom of the figure. The object is now in state W and in its 
substate U, and if method f occurs this causes the static reaction to be taken, 
which involves performing action act(). The active configuration of the object 
does not change, and it remains in U. Semantically, each static reaction in a 
state can be regarded as a transition in a virtual substate that is orthogonal to 
its ordinary substates and to the other SRs of the state. Thus, the statechart of 
Fig. 2 (b) describes the same behavior of that of Fig. 2 (a). 

Statemate is based on the structured analysis paradigm, where the func- 
tional capabilities of the system are captured by activities that are dynamically 
linked to states in the statechart. Linking states to activities is not relevant to 
Rhapsody. As mentioned before, in Rhapsody the mode of an object of a 
reactive class is the active configuration of the object’s statechart. 

The behavior of a system described in Rhapsody is a set of possible runs. 
A run consists of a series of detailed snapshots of the system’s situation. Such a 
snapshot is called a status. The first in the sequence is the initial status, and 
each subsequent one is obtained from its predecessor by executing a step (see 
Fig. 3). The heart of the semantics, and the main goal of this paper, is to define 
the effect of a step. 

Each step is composed of microsteps, as is shown by “zooming-in” on one 
of the steps in Fig. 3. The system, being in a certain status and as a response to 

1 The original version of Rhapsody used C++ as the implementation language, but 
current versions support also C, Java and Ada. 
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(a) 





Fig. 2. Static reaction 

an occurrence, undergoes a series of microsteps as part of the run-to-completion 
principle, until it reaches a final status, and at which point it is ready for the 
next occurrence. Thus the run-to completion principle applies to a step, and it 
means that as a response to some external occurrence a sequence of microsteps is 
performed leading to a final status for this step, at which point a new occurrence 
is considered, initiating a new step. A special case is that of null transitions, that 
is, transitions without a trigger, and these can be taken spontaneously. A loop 
of null transitions could in principle cause an infinite number of microsteps to 
be taken in a single step. However, in Rhapsody this is avoided by the system 
setting a maximum value for the number of null transitions that can be taken 
as part of a step, and informing the user if this bound is violated. 

Certain invariants regarding the system’s behavior (e.g., being in an OR- 
state requires being in exactly one of its substates) hold at the beginning and 
end of a step, but not necessarily in each of the microsteps. Also, a microstep 
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can correspond to performing an action in the implementation language, which 
can take time. As a consequence, in Rhapsody a statechart may reside in an 
OR-state for some non-zero time prior to entering one of its substates. 

Rhapsody supports the development of reactive multi-threaded applica- 
tions. In such applications each thread can perform steps in parallel to the 
other threads, which makes the definition and behavior more complicated. This 
topic will be discussed in Section 10, by explaining how threads are introduced 
into statechart-based systems and how the semantics are defined for them. 
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Fig. 3. The step model 



A status contains information about all the objects in the system — the states 
in which the object currently resides, history information for states, values of 
data members, connections of relations and aggregations and event queues. 

Here are some general principles adopted in defining the Rhapsody seman- 
tics: 

1. Changes that occur in a step may be sensed in the same step. There is no 
double buffering to prevent effects from being sensed immediately. This approach 
is the one more suited to the Rhapsody context, since a system consists of 
classes, not all of which have statecharts, and the guards and actions are written 
in the implementation language. Double buffering would have entailed a high 
overhead. 

2. In Rhapsody, unlike the situation in Statemate, it is possible that many 
steps will be executed between the time an event is generated and put in the 
proper event queue and the time it is dispatched to the statechart. Once an event 
is dispatched to the statechart it will “live” for the duration of one step only, 
and will not be remembered in subsequent steps. 

3. Calculations in one step are based on the current values of data members 
and the state configuration. When performing a microstep, first the set of rele- 
vant transitions is computed and only then are these transitions actually taken. 
Since there is no buffering as in Statemate, the calculation itself can effect 
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the data members; an evaluation of a guard that has side effects can affect the 
system. It is not considered good practice to use guards with side effects. 

4. A maximal subset of nonconflicting transitions and static reactions is al- 
ways executed. We refer to this as the “greediness property” of the semantics. 

5. The execution of a step does not necessarily take zero time. The time 
a step will take depends on the actions that are performed while taking the 
step, mainly those actions corresponding to method calls in the implementation 
language, and thus are not zero time. Rhapsody supports two models of time, 
real and simulated. More on these in section 9. 



3 Basic System Reaction 

A statechart describes the behavior of all instances of a class, but each instance 
(i.e., each instance’s statechart) can be in a different active configuration. After 
the instance is created a special method, startB ehavior , is invoked, initializing 
the behavior of the reactive object and causing its statechart to enter an active 
configuration according to the default transitions taken from the root. The active 
configuration can change according to the messages received by the object and 
the transitions that are performed. The object terminates its life-cycle if it is 
explicitly deleted or its statechart enters a termination connector. 

Statecharts can react to messages by performing a transition from an active 
configuration to a new active configuration and possibly performing an action. 

We now define the reaction of the system during a simple step: how the 
status of the system changes when performing a single transition between two 
OR-states with the same parent state. Assume that the object in question is 
in state A in the statechart of Fig. 4(a), and message m (event or triggered 
operation) is dispatched to the statechart of the object. 

The response of the system will be as follows: (i) The exit action of state A is 
performed. ( ii ) The action act specified by the transition is performed, (in) The 




(a) 



(b) 



Fig. 4. A simple transition 
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entry action of state B is performed. ( iv ) The active configuration is updated, 
and the object is ‘placed’ in state B. The new active configuration of the example 
is shown in Fig. 4(b). 

The action act may be of the form actl\ act.2; ... actj. In Rhapsody, actions 
are guaranteed to be performed in sequential order, each action being executed 
after the previous has terminated. This in itself does not cause a racing condition. 
The motivation for this semantics is that actions are written as code in an object- 
oriented programming language and thus sequential ordering without any double 
buffering is a natural choice. 

The behavior described in Fig. 4 could actually be part of a larger step, 
during which in some microstep the triggered operation m occurs and activates 
the response described above. 

Statecharts can communicate via an asynchronous communication mecha- 
nism that uses events and a synchronous communication mechanism that uses 
triggered operations. In Fig. 4, for example, the message in can be either an 
event or a triggered operation. We now discuss the two cases and the differences 
between them. 



3.1 Events 

Events are used to describe asynchronous communication. They are entities of 
the model and are defined as part of a package. Each class defines the set of events 
it can receive. The main motivation for using events is that the sender object 
can continue its work without waiting for the receiver to consume the event. 
Events can also be used early in the system development process, and later, 
when a better understanding of the system is gained and decisions regarding 
synchronization are made, some of these events can be converted to triggered 
operations. 

Events are sent by applying the GEN method to the destination object: 
O —> GEN(event(pi,p2,- ' ■ Pn)) The sending object should be able to refer 
to the destination object O (possibly using a navigation expression based on 
relations in the model). Here P\,P 2 , ■ • ■ Pn a re event parameters that match 
the event’s formal arguments (data members). The GEN method creates the 
event instance and queues it in the event queue of O’ s thread. In this section 
we assume a single system thread, and thus all events are handled by the same 
event queue. In a multi-tlrreaded application (see Section 10) there is an event 
queue for each thread. 

Events are managed by an event dispatcher in a queue. Once an event gets 
to the top of the queue, the dispatcher delivers the event to the proper object. 
When an object receives an event, it will process it according to the run-to- 
completion semantics. After processing, the event no longer exists and is deleted 
by the computational framework. Between the time an event is generated and 
put it in the queue and the time it is dispatched to the destination object, the 
destination object could be destroyed, in which case all events that were sent to 
it will be deleted and will have no effect. 
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Fig. 5. Communication using events 



Consider the system in Fig. 5, with objects 0\ and O 2 of classes C\ and C 2 , 
respectively, and with a one-to-one relationship between the objects. If object 
0\ receives event e (say, from the user), the transition from state A to state B is 
taken, involving sending event / to object O 2 (by placing a new event / in the 
event queue), as specified by the action getltsC 2() — ► GEN(f), since O 2 is the 
object that it recognizes from class C 2 . Once the transition to state B of 0\ is 
completed, event / is removed from the event queue, and is dispatched to object 
O 2 , causing it to take the transition from its state A to state B. In a similar way, 
object O 2 now sends event e to Oi, and the process repeats itself. In this way, 
a feedback loop is created, with objects 0\ and O 2 repeatedly moving between 
states A and B , and sending events e and / to each other, ad infinitum. 

Unlike Statemate, there is no special treatment of internal events in Rhap- 
sody. Sending events internally is done simply by omitting the destination object 
from the send operation, as follows: 

GEN(event(pi,p 2 ,- ■■ Pn )) 

Consider Fig. 6. On creation of an object of this class the statechart is ini- 
tiated, and the default transition to state A is taken, performing the action 
GEN(e( 1)), which causes the internal event e with parameter value 1 to be 
sent. Only after the object has completed the transition and is in state A , is the 
event e dispatched to the statechart. Processing this event causes a transition to 
state C, since of the two outgoing transitions from the condition connector, the 
guard of the transition to state C is satisfied (the parameter of the event in the 
transition is referenced using the par ams — > command, and here the value was 1). 

Events are independent entities of the model and can be sub-classed like 
inherited objects, a mechanism that can be used in order to add attributes — 
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Fig. 6. More communication using events 




event parameters. In particular, if event e2 is derived from event e in this way, 
e2 will trigger any transition that has e as a trigger. For example, in Fig. 7, 
after taking the default transition into state A and sending event to itself, the 
transition to state B is taken, since e 2 inherits from event e. 



3.2 Triggered Operations 

Triggered operations are services provided by a class, and are defined as part 
of the serving class. They are a synchronous communication means between a 
client and the server object. A triggered operation may return a value to the 
client object, since its activation is synchronous. 

Unlike events, triggered operations are not independent entities; rather, they 
are part of the class definition, and are not organized in hierarchies. The use of 
a triggered operation corresponds to the invocation of a class member function. 
The main reason that triggered operations were integrated into the Rhapsody 
framework was to allow the usage of statecharts in architectures that are not 
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Fig. 8. Using triggered operations 



event-driven, and thus to specify the behavior of objects in the programming 
sense of operations and object state. Triggered operations also provide means for 
late design decisions to optimize execution time and sequencing, by converting 
event communication into direct triggered operation invocation. 

A triggered operation is invoked like a primitive operation in the underlying 
implementation language: 

result = O — > t(pi,p 2 ,- ■ ■ pn ) 

A triggered operation may return a value whose type is the one defined in 
the object model, where the operation interface is defined. The return value for 
a triggered operation must be set within the transition. Replying to a triggered 
operation is done by calling the reply method defined for the class. The following 
transition label specifies a reply to the operation t: 

t/reply{n) 

Consider the two statecharts of classes X and Y, described in Fig. 8 (a). If 
an object of class X receives the event go , a transition from state A to state B 
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is taken, which invokes the triggered operation t in the relevant object of class 
Y, as specified by the action getItsY() t(). The transition to state B of X 
is not completed before t is processed, causing the Y object to move from state 
A to state B , with 10 being the returned value of t. The figure shows the active 
configuration of the stateclrarts in animation mode, at a point when the Y object 
has completed its transition to state B , and the X object is in the midst of the 
transition. The X object’s transition is completed after setResult is called with 
the value 10 that was returned by the triggered operation, and the value of the 
data member result of X is updated. Only then is state B entered. 

One thing that has to be resolved here is the reaction of an object to an 
invocation of a triggered operation when it is not in a stable state, i.e., when it is 
in the midst of performing a transition. This is especially relevant in Rhapsody, 
since transitions do not take zero time. This would not be a problem if we 
considered only events, since events represent asynchronous communication and 
are queued; the next event is taken from the queue only after the step completes, 
so that the run to completion semantics assures the object is in a stable state. 
For triggered operations there is no such assurance. 

This situation is demonstrated in Fig. 8 (b). While taking the default tran- 
sition to state 51, event e is generated, causing the transition from state 51 to 
state 52. However, during the process of carrying this out, the action t() is per- 
formed which invokes the triggered operation t on this statechart. There are a 
number of alternatives for dealing with this kind of situation: One is to treat this 
as a deadlock, and a problem in the design. Another is to allow the transition 
to be completed and state 52 to be entered, and only then to process t, causing 
a transition to be taken back to state 51. 

In Rhapsody, a different choice was made: the invocation of a triggered 
operation t in the midst of a transition causes no effect, and the return value 
from such a call is undefined. In the above example, the object completes its 
transition to state 52 and remains there. The semantics is implemented by a 
locking mechanism that causes an object to ignore the invocation of triggered 
operations while in the middle of a step. A self call such as that in the example 
is a special case, but in general this can also occur as the result of a chain of 
calls between different objects, ending in a triggered operation invocation to one 
of the objects that is still in the process of performing a transition. 

Earlier, in Fig. 5, we showed an example of a feedback loop between two 
stateclrarts. If we modify this example so that e and / are triggered operations 
instead of events, as shown in Fig. 9, then the result of invoking e on 0\ is that 
both objects enter state B. In this case, the feedback loop does not close, since 
when O 2 takes the transition to state B and invokes e on 0 1 , 0\ is still in the 
middle of the transition between A and B; hence e is ignored. Once both objects 
are in state B, if e is externally invoked on 0\ (or, alternatively, / is invoked 
on 0 2 )i both objects take transitions to state A and remain there. Notice that 
had we changed only one of the two events to a triggered operation and left the 
other as an event, the feedback loop would have remained. 
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Fig. 9. Coordinated transitions 



4 Compound Transitions 

Statecharts allow defining transitions in a richer way then just by the simple 
directed arrow that connects two states, of the kind shown in Fig. 4. This general 
construct is called a compound transition (CT) and may consist of a number 
of separate transitions appearing in different orthogonal state components. Each 
of these, in turn, may consist of a number of linked transition segments, which 
are the labeled arrows that connect states and connectors of various kinds. This 
section explains how transition segments are combined to form a compound 
transition (CT). We explain the semantics of the different types of connectors 
and restrictions on how they are used. 

The connectors come in two different types: AND and OR. The fork and 
join are AND connectors. The transition segments connected to an AND con- 
nector will all participate in the same CT. Consider the statechart appearing in 
Fig. 10. It the object is in state A and the trigger e occurs, the CT transition 
is taken, causing entrance to state Cl in orthogonal component C and entrance 
to D 1 in orthogonal component D. The fact that the fork is an AND connector 
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Fig. 10. A fork connector 




Fig. 11. A join connector 



implies that both the transition segment leading to state Cl and the one leading 
to D 1 must be taken as part of the CT. The destination of a fork segment must 
be a state or a history connector and the segment cannot have a label. 

An example of a join connector is shown in Fig. 11. If the object is in states 
B 2 and C 2 and in either D 1 or D 2 and the trigger e occurs, the CT is taken, 
which causes a transition to state E. The fact that the join is an AND connector 
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Fig. 12. A junction connector 




Fig. 13. A construct equivalent to a junction connector 



implies that both the transition segment leading from state B 2 and the one 
leading from state C 2 must be taken as part of the CT. The transition segments 
entering the join connector cannot have labels. 

The junction and condition are OR connectors. Of the transition segments 
connected to an OR connector exactly one incoming transition segment and 
exactly one outgoing transition segment must participate in the CT. 

An example of a junction connector is shown in Fig. 12. If the object is in 
state A and the trigger el occurs, or it is in state B and the trigger e2 occurs, 
a transition to state C is taken. In terms of the active configuration of the 
statechart, an equivalent statechart has two separate transitions, one from state 
A and one from state B , as shown in Fig. 13. The label is either written on each of 
the transition segments entering the junction connector, as in Fig. 12, or on the 
common transition segment exiting the junction connector, as shown in Fig. 14. 

A condition connector has one incoming transition and can have several 
outgoing transition segments called branches. Branches are labeled with guards 
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Fig. 14. A junction connector with a common label 
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Fig. 15. Nested condition connectors with a common label 



that determine which one is to be actually taken. Since the condition connector 
is an OR connector, only one of the branches can be taken. If the guard of more 
than one of the branches holds then one is chosen arbitrarily. Each condition 
connector can have one special branch with a guard labeled else , which is taken 
if all the guards on the other branches are false. Branches cannot contain triggers, 
but in addition to a guard they may contain actions. A branch can enter another 
condition connector, thus providing for the nesting of branches. An example is 
shown in Fig. 15. 

When taking a transition, first the guards are all evaluated, and only then 
are the actions performed. In the statechart described in Fig. 16, for example, 
the state that is reached is B. The reason is that first the transition to be 
taken is selected by evaluating the guard, and in this stage x = 1; only when 
performing the transition is the action x = 2 performed, but it cannot influence 
the transition taken. 

A step always leads from one legal state configuration to another. A state- 
chart can not remain “stuck” at a connector (with the exception of a termination 
connector). Similarly, a statechart cannot be in a non-basic state without the 
ability to enter appropriate substates. For this reason, every OR state with more 
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Fig. 16. A condition connector 




Fig. 17. A default connector 



than one substate must have a default connector with a transition to one of the 
OR state’s substates. If a destination state of a CT causes a statechart to enter 
a non-basic state, the default transition associated with this state will be taken. 
For example, if the object in Fig. 17 is in state A and e occurs, the transition to 
state B is taken, followed by the default transition to state C. 

Taking a default transition is considered to be a microstep. Attributes get 
their values just prior to the microstep and not the values present at the begin- 
ning of the entire step. Thus, in Fig. 18, if the object is in state A and e occurs, 
the transition to state B is taken, and this is followed by the default transition 
that leads to state C, since the action x = 1 is performed before the default 
transition’s microstep is taken. 

As part of a CT, it is possible that several default transitions are taken, 
each one leading to a deeper state in the hierarchy until finally a basic state is 
reached. Each such default transition is a microstep and actions performed in 
the previous microsteps are taken into account. 
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Fig. 18. A default transition as a microstep 



5 Dealing with History 

A history connector is used to store the most recent active configuration of a 
state. Each state can have at most one history connector. The semantics of the 
history connector is that when the connector is the source of a CT, the statechart 
transitively enters the most recently visited active states. 

An example of a history connector is shown in Fig. 19. If the object is in state 
A, but has never yet entered state B, and the trigger e occurs, a transition to the 
history connector is taken, followed by the outgoing transition from the history 
connector to state D. Next, if the trigger / occurs the transition to state F is 
taken. Later, if the trigger / occurs again the active configuration is stored by the 
history connector and the transition to state A is taken. Finally, if the trigger 
e occurs, state D and then its substate F are entered, since they constituted 
the last active configuration prior to state B being exited. States D and F are 
entered without taking the outgoing transition from the history connector and 
without performing default transitions or any actions associated with them. 

Unlike Statemate, the semantics of the history connector in Rhapsody is 
the “deep history” semantics (in [4] this is associated with the special notation 
H*), which entails entering the substates of the most recent active configuration 




Fig. 19. A history connector 
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recursively, until basic states are entered. The shallow semantics of Statemate 
is not supported in Rhapsody. 

Also unlike Statemate, currently Rhapsody does not support the history— 
clear(S) operation, which erases the history of state S , thus causing the next 
transition to the history connector in S to proceed via the default transition as 
if it were the first time S is entered. 

6 The Scope of a Transition 

In taking a transition from a source to a target, a CT will often pass through dif- 
ferent levels of the statechart hierarchy. As part of performing the CT this causes 
exiting some of the states and entering others, and performing the appropriate 
exit and entry actions. 

The goal of this subsection is to define the scope of a transition, thus de- 
termining which states should be exited and which entered while taking a CT. 
The definition of the scope is the same as in Statemate, and we repeat it here 
for self containment. There are some differences in the usage of the definition, 
which are discussed later. 

Before presenting the definition, consider the simple case of the statechart in 
Fig. 20. Taking the transition with trigger e causes exiting state B and entering 
state C. Any relevant entry and exit actions are performed. The scope of this 
transition is state A. 

The scope of a CT is the lowest OR state in the hierarchy of states that is 
a proper common ancestor of all the source and target states. Taking the CT 
will result in a change of the active configuration involving only substates in 
the scope. When the CT is taken, all the proper descendants of its scope in 
which the system resided at the beginning of the step are exited, and all proper 
descendants of that scope in which the system will reside as a result of executing 
tr are entered. Thus, the scope is the lowest state in which the system stays 
without exiting and reentering when taking the transition. 

We now illustrate the notion of scope by some examples. Consider the state- 
chart of Fig. 21 (a). If the associated object is in state W and message e occurs, 




Fig. 20. The scope of a transition 
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Fig. 21. The scope of a transition 




Fig. 22. More on the scope of a transition 



the transition with scope U is to be taken, since according to the previous defini- 
tion U is the lowest OR state in the hierarchy that is a proper common ancestor 
of V. Thus, taking the transition implies exiting states W and V and entering 
states V and W. We defined U to be the scope of the transition since we con- 
sider state V to be both the source and the target of the transition. Notice that 
although the (implicit) default transition to state W is taken, we still consider 
V to be the transition’s target since the default transition is taken as part of a 
new microstep. This is important, since if the statechart was modified so that 
the source of the transition becomes W, as shown in Fig. 21 (b), considering W 
to be also the target of the transition would have implied that V is the scope of 
the transition, while in fact according to our definitions U is the scope. 

Consider the statechart of Fig. 22. If the associated object is in states B 2 and 
Cl and receives message /, it takes a compound transition, causing it to enter 
states C2 and B 1 (the latter by the default transition). According to the previous 
definition, S is the scope of the transition, being the lowest OR state in the 
hierarchy of states that is a proper common ancestor of states B 1, B 2, Cl and C2. 
The states exited are B2, B 1 Cl, C and A, and those entered are A , B, Bl, C and 
C2. Notice that the notion of scope does not depend on the way the transition 
itself is drawn, but on its sources and targets only: the transition in Fig. 22 is 
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drawn inside state A but this does not cause A to be the scope of the transition 
rather than S. Even if the transition would have be drawn as exiting the contour 
of S, the scope would still be S. 



7 Conflicting Transitions (Nondeterminism) 

We say that two transitions are in conflict if there is some common state that 
would be exited if either of them were to be taken. Consider the stateclrart in 
Fig. 23 (a), the two outgoing transitions from state A labeled e are in conflict 
because they would each imply exiting state A. The transition from state U to 
state D is in conflict with the two outgoing transitions from state A and also 
with the transition from state B to state C, since if the transition from U to D 
is taken it implies also exiting whatever substate of U the object was in. 

Two conflicting transitions cannot be taken in the same step. If they are both 
enabled only one will be taken. We now explain how this choice is made. 

The two types of conflicts in Fig. 23 (a) are treated differently. If the object 
was in state A and message e occurred the system is faced with nondeterminism, 
since there is no reason to prefer a transition to one of the states B and C over the 
other. Rhapsody detects such cases of nondeterminism during code generation 
and does not allow them. The motivation for this is that the generated code 
is intended to serve as a final implementation and for most embedded software 
systems such nondeterminism is not acceptable. 2 

The second case of conflict in Fig. 23 (a) is that between the transition from 
A to B (assume that the transition between A and C has been removed) and 
the transition from U to D. In Rhapsody, when a message can trigger several 
conflicting transitions priority is given to lower level source states. Hence, here 
the transition from A to B takes priority over the one from U to D, and there 
is no nondeterminism. At the end of the step the object will be in state B. 
Join transitions get priority according to their lower source state. If there is no 
lrierarchal relation between the source states no priority is defined between the 
transitions. This priority strategy is different than that of Statemate, which 
determines priorities outside-in; in our case according to Statemate the object 
will end up in state D. The strategy in Rhapsody is more object-oriented, since 
it enables substates to override transitions in higher states in a way similar to 
that in which operations in subclasses can override those of the superclass. 

Another technical difference between Statemate and Rhapsody is that 
in Statemate we determine priorities outside-in according to the scope of the 

2 We suggest that an option be provided to the user to allow such nondeterminism, 
which can be useful in certain development stages where the model is not yet com- 
plete. In any case, the current implementation cannot block all nondeterminism when 
performing code generation, since we may have conflicting transitions with the same 
trigger but with different guards, and in general it is impossible to detect at compile 
time whether both guards will evaluate to true. 
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Fig. 23. Conflicting transitions 



transition, while in Rhapsody we determine priorities inside-out according to 
the source state. Consider the statechart in Fig. 23 (b). If the object is in state 
E and message e occurs, then in Rhapsody we take the transition to state F, 
since the source of this transition E is lower than the source of the transition to 
state C which is B. In Statemate the scope of both transitions is A, resulting 
in nondeterminism. 

The priority of a static reaction is determined according to the state in which 
it is defined, giving high priority to lower-level states. If a CT and a SR are in 
conflict, the one with lower source state will be taken and the other will not. If 
the CT and SR have the same source state, as in Fig. 24, the CT has higher 
priority, thus the transition to state B will be taken and the static reaction will 
not be carried out. This is different from the Statemate approach, were an 
enabled static reaction defined in state S is executed if the system was in S at 
the beginning of the step but S was not exited by any CT during the step. 



8 The Basic Step Algorithm 

In this section we present a schematic description of the algorithm that executes 
a step. For a single threaded application, we do the following repeatedly: 

If the event queue is not empty, get the next event and its destination from 
the queue. If the destination object still exists dispatch the event to that ob- 
ject’s statechart. The event invocation may cause taking SRs or CTs and all 
the relevant default transitions, as explained in earlier sections. At the end of 
the run-to-completion the statechart of the object is in a (possibly new) ac- 
tive configuration. If the statechart does not specify a transition in response to 
the event, the active configuration remains unchanged. The loop can now be 
continued, processing the next event. 
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Fig. 24. Conflict between transition and static reaction 



A pseudocode description of the procedure is: 

procedure StepCycle () 
begin 

loop forever 

while Event- Queue / empty do 
ev <— Get- Event- From- Queue 
dest <— Get- Destination- Of- Event 
if dest still exists then 
dest — > takeEvent(ev ) 
else 

Ignore ev 

end if 
end while 
end loop 
end 

Here now are the details of the main part of this procedure ( takeEvent ), in 
which an event is processed by the statechart. 

— Determine the CTs/SRs that will fire in response to the message: Traverse 
the states in the active configuration from lowest states in the hierarchy 
upwards. A CT/SR is enabled if its trigger is the dispatched event ev or a 
super-event of ev, and the guard evaluates to true. Since for a given state CTs 
have priority over SRs, they are considered first. Once an enabled transition 
is found with a given source state stop traversing the states that are higher 
than this state in the hierarchy. States in orthogonal components are still 
considered since they may be taken without necessarily causing a conflict. 

— Perform the CTs/SRs that we found should fire: 

For each transition do: 




348 



D. Harel and H. Kugler 



• Update histories of exited states. 

• Perform the exit actions of the exited states according to the order states 
are exited, from low state to high state. 

• Perform the actions on the CT/SR sequentially according to the order 
in which they are written on the transition, from the action closest to 
source state to the action closest to target state. 

• Perform the entry actions of the entered states according to the order 
states are entered, from high state to low state. 

• For lowest level states that were entered, which are not basic states, per- 
form default transitions (recursively) until the statechart reaches basic 
states. 

• Update the active configuration. 

The order of firing transitions of orthogonal components is not defined, and 
depends on an arbitrary traversal in the implementation. Also, the actions on 
the transitions of the orthogonal components are interleaved in an arbitrary 
way. 

— Deal with null transitions: After reacting to a message, the statechart may 
reach a state configuration where some of the states have outgoing enabled 
null transitions — transient configurations. In such a case further steps need 
to be taken until the statechart reaches a stable state configuration where 
no null transitions are enabled. Null transitions are triggered by null events 
that are dispatched to the statechart whenever a transient configuration is 
encountered. Null events are dispatched in a series until a stable configura- 
tion is reached. It is possible that the statechart will never reach a stable 
configuration; for example when there is a loop of null transitions. In Rhap- 
sody the infinite loop is detected during runtime and execution is halted. 
It is possible using the execution framework to set a maximum value for 
null transitions. When performing the null transitions, each one is taken 
separately and the values used in the computation are the values after the 
previous null transition and not the values before the entire step. 

— Wrap up: Once a stable configuration is reached, the reaction to the message 
is completed, control returns to the dispatcher and new messages can be 
dispatched. 



9 The Time Model 

The Rhapsody time model is more complex than that of Statemate, since 
Rhapsody allows describing both synchronous and asynchronous behavior in 
the same model. Moreover, a step does not necessarily take zero time. Due to 
these facts, the synchronous time model of Statemate is not relevant here. 
Rhapsody supports two different modes of handling the progress of time: real 
time and simulated time. In real time mode time advances according to the actual 
underlying operating system clock. In simulated time the user of Rhapsody 
can control the progress of time in an interactive way, thus enabling effective 
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debugging and testing of the model. A detailed description of the Rhapsody 
time model will appear in the full version of the paper. 

Recall that all aspects of the execution of a Rhapsody model, and this 
includes timing aspects too, are carried out via the generated code. This is 
important in Rhapsody, since one of the main goals is to develop production- 
code. However, there are many interesting opportunities for further research 
on the timing aspects of modeling object-oriented systems, especially regarding 
the simulated time mode. In fact, we predict that analytic techniques could be 
modified to apply to timed behavior, in ways that do not depend directly on the 
generated code and are thus more robust. 

10 Multi-threaded Systems 

Rhapsody supports the development of reactive multi-threaded applications. 
In such applications each thread can perform steps in parallel to the other 
threads. Obviously, this makes the definition and behavior more complicated. We 
now discuss this topic in some detail, by explaining how threads are introduced 
into stateclrart-based systems and how their semantics is defined. A detailed 
description of this topic will appear in the full version of the paper. 

An object-oriented system consists of objects exchanging messages. The ideal 
analysis view of such a world is that each object is an autonomous entity exe- 
cuting concurrently with all other objects. In order to have a more realistic and 
concrete model, this general abstraction can be given various interpretations, 
regarding the synchronization between objects and the semantics of messages. 

In the synchronous model objects execute on a clock edge, and the period 
between two clock edges is called a step. This model is similar to digital hard- 
ware systems, where all components are synchronized by a clock. It is also the 
model implemented in Statemate, and although Statemate is executed on 
a sequential machine and concurrency is achieved by simulation, messages sent 
at a certain step being processed in the next step. The major advantage of this 
model is that it is deterministic and simple. However, it does not fit software 
systems for the following reasons: Software systems have a very limited form of 
concurrency, since in general they run sequentially on the same CPU. Also, in 
the case of concurrent software, tight synchronization is an undesired overhead, 
so that concurrent software components are by default asynchronous unless they 
are explicitly synchronized. 

Since real concurrency does not exist in most software applications, the CPU 
is shared by all software objects. The sequence in which software functions ex- 
ecute is known as the thread of control, which can be thought of as a token 
(representing the CPU) passed between objects in the system, enabling them 
to execute. Initially, the token is given to the main program, and it is typically 
passed along by method activation. A client object sending a message to a server 
object actually gives up its control of the CPU in favor of the server object. This 
passing along can be nested, with ol calling o2, who calls o3, and so forth. 
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In the general case, a system will have more than one thread, which means 
that conceptually it has multiple tokens, and this is a far more complicated setup 
than a single-threaded one. We now discuss the way Rhapsody deals with some 
of the major issues in multi-tlrreaded systems: thread creation and destruction, 
associating objects with threads, and communication and synchronization be- 
tween threads. 

Object/thread relationship: An important issue in a multi-threaded sys- 
tem has to do with which objects belong to which thread. In Rhapsody, a class 
can be defined as an active class and then each of the instances of this class 
will have its own thread of control. Another way of defining the object/thread 
relationship is through composition. Instances that are components of a com- 
posite class run on the thread of the composite class, unless they are instances 
of an active class, in which case they have their own thread. 

Instances of classes that are not designated as active classes run on the unique 
system thread, which is the default thread used by the main program. 

It is also possible to set the thread of an object explicitly, by calling the 
setThreadO command. This gives developers more control over threading poli- 
cies. However, it also introduces many delicate issues, such as thread destruction 
policy, and how to transfer events to the new event queue after an object changes 
its thread. Some of these issues of dynamic object/thread relationship require 
further research to enable automatic support for more complicated groupings. 

Creation and destruction of threads: The special system thread is cre- 
ated when the main program for the executable model is started. This thread 
will be destroyed only when the application terminates. Creating an object that 
is an instance of an active class causes the creation of a thread on which this 
object runs. This thread is destroyed when the object is destroyed, which can 
happen explicitly from the outside, or by the object’s stateclrart entering a ter- 
mination connector. In the case where components of a composite class run on 
the thread of that composite class, destroying a component does not cause the 
destruction of the thread; the thread will be destroyed when the composite class 
object is destroyed. 

Automatic support for thread destruction in the case of explicit setting of an 
object’s thread is not currently supported by Rhapsody. A possible solution is 
to destroy the thread only when the last object running on the thread is deleted. 

Communication and synchronization between threads: As discussed 
previously, the stateclrart of an object can deal with asynchronous communica- 
tion using events and synchronous communication using triggered operations. In 
the multi-threaded case, an object can receive messages from different objects, 
each having its own thread of control and therefore running concurrently with 
other objects. 

The case of asynchronous communication using events is simpler: The gen- 
erated events are put in the event queue of the receiving object and are later 
dispatched to the stateclrart. In the case of synchronous communication using 
triggered operations, the sending object is blocked until the receiving stateclrart 
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completes its response to the triggered operation. Hence, if different threaded 
objects invoke a triggered operation on the same statechart they will be posted 
to the statechart one at a time and each sending object is blocked until its in- 
vocation is completed. Situations of deadlocks and starvation are possible, and 
must be avoided as part of the model design. 

Classes can also communicate by calling member functions; i.e., primitive 
operations. Since synchronization in multi-tlrreaded applications is important, 
Rhapsody allows the definition of guarded primitive operations. All the guarded 
primitive operations of a class are mutually exclusive, in that only a single op- 
eration can run at any given time and the other invocations are blocked. Oper- 
ations that are not defined as guarded can run in parallel. Triggered operations 
can also be defined as guarded, thus causing all guarded operations (primitive 
or triggered) of the class to be mutual exclusive. 

The step algorithm for a multi-tlrreaded system consists of performing the 
step cycle described in the basic step algorithm for each thread. There are several 
complications in the semantics relative to the single-threaded case. For exam- 
ple, when one thread is in the middle of performing a step (and as explained 
earlier, this might take more than zero time), a second thread can interact with 
it by invoking primitive or triggered operations or sending events. For events, 
the Rhapsody execution framework guarantees that the event queue is not cor- 
rupted by different threads interacting with it simultaneously, and that events are 
not lost. This is achieved in Rhapsody by locking mechanisms. Before access- 
ing the event queue a lock() command is invoked, which prevents other threads 
from interfering with the queue. Only after the interaction with the event queue 
is over does the unlock() command allow other threads to lock the queue and 
use it. The code generation framework in Rhapsody implements the lock() and 
unlock() commands using a mutual exclusion mechanism in the underlying oper- 
ating system. In the multi-tlrreaded case, these locking mechanisms can prevent 
an object attempting to send an event from proceeding until it manages to per- 
form the lock. In contrast, the single-threaded case allows the sending object to 
generate an event and continue progress immediately. 



11 Racing Conditions 

A racing condition occurs when the execution of transitions in two different 
legal orders would cause the system to end up in two different configurations. 
In Statemate, the semantics and execution model were simpler, and this al- 
lowed the tool to detect and report such conditions. The fact that Rhapsody 
deals with synchronous and asynchronous communication and well as with multi- 
threaded applications, and the fact that a step does not take zero time, make 
automatic detection and reporting of racing conditions a much harder task, and 
Rhapsody does not attempt to undertake it. Developing tool support to handle 
these issues requires further research. Until this situation changes, users of tools 
that deal with such advanced features are advised to make efforts to avoid racing 
conditions by improving and tightening their models. 
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12 Comparison with Other Work 

Readers interested in comparing the Rhapsody semantics of statecharts with 
non-00 approaches to statechart semantics are referred to the discussion in Ap- 
pendix A of [6]. We now briefly discuss appropriate object-oriented approaches. 

ROOM: The ROOM method of [12], and its supporting tool ObjecTime 

(which later evolved into Rose-RT) were the first to introduce extended state- 
machines into an object-oriented paradigm in a way that allows development of 
fully executable models. The main formalism for describing behavior in ROOM 
is called ROOMclrarts, which was inspired by the original statechart formalism 
[4]. ROOMclrarts allow lrierarchal nesting of OR-states but not orthogonality 
(AND-states), which thus renders the language much simpler. The semantics of 
the language is based on the run-to-completion principle, and an assumption is 
made that the time taken to process any single event should not exceed the max- 
imum latency requirements of the object. The communication between objects 
implemented as ROOMclrarts can be carried out using asynchronous events and 
triggered operations of Rhapsody, and there is a mechanism for defining event 
priorities. 

UML 2.0: In the very recent UML 2.0 there is a distinction between two 

kinds of state machines (both are variants of statecharts): behavioral state 
machines and protocol state machines. Behavioral state machines are really 
the original 00 statecharts of [5] and the present paper, and they are used to 
describe the behavior of an object. In contrast, protocol state machines describe 
usage protocols, and are thus geared to specifying requirements of classes, in- 
terfaces and ports, rather then defining the entire behavior of an object. In the 
behavioral statecharts of UML 2.0 shallow history is allowed too, in addition to 
deep history. Triggers can be signals (corresponding to events in our paper) or 
operations (corresponding to our triggered operations) . The semantics is that of 
run-to-completion [5] , and the way conflicting transitions are handled is by a se- 
lection algorithm similar to the one introduced in Rhapsody and reported upon 
here. UML allows deferred events, which are not lost if dispatched to the object 
and the event is not enabled. This extension is currently not part of Rhapsody 
statecharts. The UML allows the definition of submachines, which is a syntactic 
way to break up a statechart and describe some of the more complex lrierarchal 
states in different diagrams. This is also supported by Rhapsody, but is not es- 
sential to this paper because it is essentially a syntactic extension with virtually 
no impact on the semantics. 

It should be noted that the UML standard leaves certain semantical options 
open, thus allowing “semantic variation points”, that can be implemented dif- 
ferently by the tool vendors or according to the application domain. 

Semantics for formal verification: Following the publication of [5] and 

the release of Rhapsody, and aided by the growing popularity of the UML [13], 
its application to safety-critical systems, and advances in the field of formal ver- 
ification, extensive research efforts have been invested in formalizing the UML. 
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The main goal is to develop formal semantics for the UML, which will make it 
possible to apply formal verification methods and tools. 

In Damm et al. [3] a kernel of the UML is defined and formalized, by asso- 
ciating a model with a symbolic transition system. Semantics of a richer UML 
subset is then defined by compiling it into that kernel. The rich subset cov- 
ers such features as active objects, dynamic object creation and destruction, 
dynamically changing communication topologies in inter-object communication, 
asynchronous signal based communication, synchronous communication using 
operation calls, and shared memory communication through global attributes. 
While the semantic model of [3] is quite general, the paper suggests certain re- 
strictions on the communication scheme between objects, in order to optimize 
the verification process. 

In contrast, Rhapsody takes a more general approach: rather than impos- 
ing restrictions, it allows users to make their own design decisions and supports 
powerful execution semantics through code generation capabilities. As the im- 
pact of formal verification methods increases and verification engines scale up to 
handle larger systems, we believe that tools like Rhapsody will be modified to 
support and take advantage of certain restrictions and semantic idiosyncracies, 
of the kinds adopted in [3] . 

A more abstract version of the semantics of [3] appears in [8] by formalization 
in the langauge of the PVS theorem prover. For more details on other UML 
verification-driven semantics, e.g., [10,2] see [3]. 
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Abstract. In this paper, we present an approach to the interactive ver- 
ification of statecharts. We use STATEMATE statecharts for the formal 
specification of safety critical systems and Interval Temporal Logic to for- 
malize the proof conditions. To handle infinite data, complex functions 
and predicates, we use algebraic specifications. 

Our verification approach is a basis for the aim of the project ForMoSA 
to put safety analysis techniques on formal grounds. As part of this ap- 
proach, fault tree analysis (FTA) has been formalized yielding conditions 
that can be verified using the calculus defined in this paper. Verification 
conditions resulting from the formal FTA of the radio-based level cross- 
ing control have been successfully verified. 



1 Introduction 

We present an approach which aims to support the interactive verification of 
(safety) properties for concurrent, reactive systems. 

We chose STATEMATE statecharts as modeling notation since they have a 
formal semantics, are broadly accepted, and STATEMATE [HLN+90] is widely 
used in industrial practice as a specification tool. Our use of statecharts over- 
comes the problem that typically engineers use more complex semi-formal lan- 
guages than the fully formal models (usually automata) used by verification 
engineers. 

Safety properties are stated in a first-order variant of Interval Temporal Logic 
(ITL, [Mos85,CMZ02]). This logic is expressive enough to describe most safety 
relevant properties. In particular a standard safety analysis technique - fault tree 
analysis (FTA) - has been formalized [STR02] . Formal FTA allows to rigorously 
prove cause-consequence relationships between individual component faults and 
failure of the whole system (see also [OTSW04] in this volume and [OT02]). 
Stateclrart verification is the basis for proving such dependencies. 

We use the KIV system [BRS + 00] as an implementation platform for the 
developed proof calculus. The proof strategy in KIV is symbolic execution. Sym- 
bolic execution is an intuitive proof method widely used for the interactive veri- 
fication of sequential programs. KIV supports Dynamic Logic (DL, [Har84]) for 
proving properties of sequential programs by symbolic execution. This proof 
method has been extended to interval temporal logic and parallel programs 
[BDRS02] as well. The main contribution of this paper is to integrate proof 
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support for STATEMATE stateclrarts. This allows us to directly use the model 
of the engineers as the formal system model. 

In Sect. 2 we present a small example to explain the basics of STATEMATE 
stateclrarts. This example is also used in Sect. 3 to demonstrate the proof strategy 
of symbolic execution informally. The logical foundations of ITL are given in 
Sect. 4. They form the basis for embedding stateclrarts in Sect. 5. The main part 
of this paper is the presentation of the proof calculus for stateclrarts in Sect. 6. 
Sect. 7 gives a statechart model of a radio-based level crossing control. Algebraic 
specifications over integers are used to specify the velocity and braking behavior 
of a train. For this specification we have verified the proof obligations of a formal 
FTA for the hazard “collision on crossing”. Finally, Sect. 8 concludes the paper 
and gives an outlook to future work. 



2 Example: Automated Light Control 

In the following, the example of an automatic light control will be used to explain 
important statechart terminology. 

The statechart in Fig. 1 models an automated light control, which switches 
off the light k minutes after the light has been switched on. Initially, the light is 
Off , the timer is Idle, and x = 0. When the press event is active, the transition 
t\ switches the light on, generates the event set to enable transition £3, and starts 
the timer. In state Cnt, the timer x is incremented through the tick event ( tick 
is generated, when the system clock advances) and finally, when x is greater or 
equal to k, the timer leaves Cnt and generates a sw.off event (£4), to switch off 
the light (*2)- 

The model of light control SYS consists of an and-state System, which exe- 
cutes the or-states Light and Timer in parallel. Off, On, Idle, and Cnt are basic- 
states, which do not encapsulate any sub-charts. states(SC) is the set of states 
of a statechart SC and states(SYS) = {System, Light, On, Off, Timer, Idle, Cnt} 
the states of the light control. Sub-charts of a state are computed by the func- 
tion childs : states(SC) —> p(states(SC)), so the childs relation describes a 
tree of states, with the root root(SC) ( root(SYS) = System, childs (System) = 
{Light, Timer}). Stateclrarts define termination- states, as well. Termination- 
states stop the execution of the statechart, but are not used in the example. The 
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Fig. 1 . Automated Light control 
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mode of a state is computed by mode : states(SC) — > {and, or, basic, term,}, e.g. 
mode(System) = and. 

The structure of a statechart defines a consistency predicate cons(SC) over 
states. If an and-state is active, every sub-state is active, as well, and if an or- 
state is active, exactly on of its sub-states is active. A configuration which fulfills 
this requirement is called consistent. E.g., a configuration, where Off and On is 
active, is inconsistent, but Off and Cnt describe a consistent configuration. 

A transition is labeled with a guard and an action. trans(SC) is the set 
of all transitions of a statechart SC. sourceft) computes the source state of 
a transition t, targetft ) the target state, guard(t) the guard and actionft) the 
action. A transition can be executed, if source(t) is active and guard(t) holds. 
Then action(t) is executed and the state targetit) is entered. For t. 4 , sourceft. 4 ) = 
Cnt, targetiti) = Idle, guardlt 4 ) = x > k, and action (t 4 ) = swmff-x := 0. 

The state transition from Off to On describes a so called micro-step. This 
micro-step triggers the transition t% and a second micro-step is executed. The 
event press activated a chain reaction of micro-steps. If no more micro-steps are 
possible, a macro-step, marked with the tick event, reads in new input values 
from the environment and time passes. While micro-steps are executed, no input 
events are considered. 

In state Cnt, the timer x is incremented in every macro-step through a static 
reaction. The set of all static reactions is sreactions(SC). Static reactions are 
assigned to a state and sreact : states(SC) —> p(sreactions(SC)) computes all 
static reactions of one state. Like transitions, static reactions sr are labeled 
with a guard guard (sr) and an action action(sr). The action is executed, if the 
corresponding state of the static reaction is active, not exited, and the guard 
holds. 



3 Symbolic Execution 

In this section we give an informal description of the proof strategy symbolic 
execution to prove properties of statecharts. If we want to prove a temporal 
logic property for the light control, e.g. that the counter is never greater than k, 
we execute the statechart and show, that in every (reachable) configuration the 
property holds. With an inductive argument we prove the property for infinite 
system traces (see Sect. 4 for details). We describe valuations of variables sym- 
bolically by equations, e.g. x < k, and therefore call the proof strategy symbolic 
execution. In our approach, states and events are boolean variables and their 
values are described symbolically, as well. A state or an event is active, if the 
corresponding variable is true. 

Let us consider the statechart of the light control. In Fig. 2 we execute the 
statechart and compute the successor configurations, depending on the active 
events. The stars * mark the currently active states, the equations beneath the 
chart the values of the variable x, and the transitions between state configura- 
tions the active events. 
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Fig. 2. symbolic execution of statecharts 



If we start in an initial state configuration, we have two successors, depending 
on the press event. If press holds we step into the state On (chart b) and generate 
the event set. Otherwise, we stay in Off and get the initial configuration, again 
(chart c). With an inductive argument, we close this branch of the proof. In 
chart b, again x = 0 and the generated set event causes a state transition to 
chart d. In chart cl, the state Cnt is active and increases x until x > k. We 
generalize x = 0 to x < k (chart e) to prove that the invariant x < k holds 
for the state Cnt. This condition allows two transitions. If x < k, we stay in 
Cnt, no further micro-step is possible and a macro-step generates the tick event 
(chart g). The tick event enables the static reaction cnt , which increases x. After 
increasing x < k, x < k holds, chart i equals to chart e, and we can close this 
proof branch by induction. Otherwise, if x > k, state Cnt will be exited, state 
Idle entered (chart f), the event sw.off generated, and x set to 0 by transition 
0. Finally, sw^off triggers transition t 2 to enter state Off. We reach chart h, 
which is equal to chart a and again use induction to finish the proof. Because 
x < k holds from chart a to chart i, the property a x is never greater than fc” is 
proven. 



Partially specified State Configurations. In the previous proof, we gener- 
alized the condition x = 0 to x < k. Analogously, we often want to prove proper- 
ties over statecharts, where the current state configuration is not unambiguously 
given. We call such configurations partially specified state configurations. 

Again, we want to prove the condition, that x is never greater than k. Be- 
cause x only changes in the chart Timer, it is no difference, if On or Off is 
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active. Because active (and inactive) states are described symbolically (e.g. On 
= true), we can generalize state configurations by omitting informations about 
states. If we prove conditions with partially specified state configurations (no 
information, if On or Off are active or not), a generalized induction hypothesis 
is possible (we can apply it in On and Off) resulting in shorter proofs. However, 
the computation of successor states gets more complex, since we have to consider 
transitions for both source state On and Off (see Sect. 6.1). 

4 The Temporal Logic Framework 

The basis of our approach is Interval Temporal Logic (ITL, [Mos85]). We use 
a first order extension based on algebraic specifications [Wir90] and consider 
finite and infinite intervals as described in [CMZ02]. The semantics is based 
on intervals / (in the following also called traces) which are finite or infinite 
sequences of states (also called valuations) / = (do,...). Every valuation ay 
maps unprimed variables a j(x) and primed variables ay (a;') to values of our 
domain. In a trace, the values of the primed variables are equal to the values 
of the unprimed variables in the next state ay (a/ ) = ay_|_i(a;). Flexible variables 
may have different values in each state, while for rigid variables ay (a:) must be 
the same for all i. Function and predicate symbols are rigid and are interpreted 
using algebras (see for example [SA91]). Possible algebras are given as the (loose) 
semantics of algebraic specifications. 

As temporal operators we use ip ; (chop - the interval can be split in two 
subintervals, such that ip holds in the first one and if holds in the second), 
(always), Oip (eventually), o ip (strong next - there exists a next state and ip 
holds then), • tp (weak next - if there exists a next state, then ip holds there)), 
ip until (until), and others with their standard semantics in ITL. Given an 
algebra, the semantics of a formula is a set of traces / = (a o, ay, . . .) for which 
the formula holds. E.g., A, I |= □ (/?, if and only if for every i < length(I) and 
A := (ay, oy+i, . . .): A , Ii |= ip. This allows to view statecharts as a special kind 
of formula, because they define sets of traces, as well. Predicate logic formulas 
<L> only depend on the first state of an interval and A,I \= < L > :-0- A, cr 0 |= If 
the algebra A is not relevant for the current consideration, we omit A. 



Sequential Programs. To define transactions and static reactions we use ab- 
stract sequential programs. Their effects are expressed using Dynamic Logic 
(DL, [Har84]) in combination with the temporal logic framework. In the follow- 
ing example we require variable x' to be equal to the value of variable x after a 
program has been executed. 

(if y = 0 then x := 1 else x := 2) x' — x 

Here, x' is either 1 or 2 depending on y. Parallel assignments will be used in the 
following. A valid formula is e.g. 



x = 1 A y = 2 — > (x, y := y, x) x = 2 A y = 1. 
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Semantically, the program of a DL operator is used to modify the first valuation 
(To of a trace, the following valuations <ri, . . . (if any) are untouched. 

(cto, <ti, •■■)[= (a) <p :<t=> there exists r with cro[a]r with (r, ay, . . .) | = ip 

where cto[q!]t is the input/output semantics of program a with input valuation 
do and output valuation r. 



Sequent Calculus. We construct proofs using a sequent calculus. Proof rules 
for predicate logic are standard. For DL we employ rules to symbolically execute 
the sequential programs. For example the two rules 



( x := t) ip,r h A 



assign left. 



e, (a) <p,r\- A {/3) <p,r \- e,A 
(if £ then a else 0) ip,T h A 



are used to execute assignments and conditionals by reducing the conclusion to 
the premise. Here, r denotes all other premises and A the rest f the conclusions. 
For a full set of rules for Dynamic Logic see for example [HRS88] . 



Rules for Temporal Logic. The same strategy of symbolic execution is ap- 
plied to temporal operators. Our first goal is to construct - for each temporal 
formula - separate formulas restricting the first valuation and the rest of the 
trace. For example □<£> in the succedent is treated as follows. 



r i- ip, a r i- • n<p, a 
r h cup,A 



always right 



In the first premise, we prove that tp holds in the first state, in the second, we 
establish the property for the rest of the trace. Application of always right can 
be viewed as unwinding (the recursive definition of) the temporal operator. It is 
comparable to executing programs. Unwinding Up and O <p is straightforward, 
for more details on unwinding p ; if and others, see [BDRS02]. 

We unwind temporal operators until every temporal formula r and A is 
prefixed with a next operator and all other formulas 7 and 6 are formulas in 
predicate logic involving unprimed and primed variables. Then we can advance 
one step in the trace by applying rule step. 



7o,r h So, A 

7, o r b (5, • a 



step 



Here 70 and ( 5 o are obtained from 7 and S by replacing all unprimed variables v 
with new rigid variables Vq and all primed variables v' with their unprimed ver- 
sion v. The leading next operators are removed. Thus we have stored the values 
of variables of the initial state of the trace in new variables Vo and advanced one 
step in the trace by removing all primes and next operators. 
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Induction. Since traces may be arbitrary long or even infinite, it is not feasible, 
to execute the whole trace. Therefore, we need induction. The basic idea is to 
advance in the trace until a state of the stateclrart is repeated and some value 
decreased. In this case we have executed a loop and if we can show an invariant 
property, the proof can be finished by induction. To prove a safety property Op, 
we use the following induction rule 



N = N' + 1 until -i p,n = N, IndHyp(n), r b A 
r b Op, A 



ind. always 



where the induction hypothesis is 

IndHyp(n) := V m < n. Cl™([\ F A m = N — > \J A) 

and Cl™(p) denotes the universal closure of p except m. The rule is based on 
the equivalence 



-i Op -o- (3 N. N = N' + 1 until -■ p) 

and wellfounded induction over N . Informally the proof is by contradiction: 
if Op is false, then there exists a number of steps after which the formula p 
becomes false for the first time. This number is the initial value of N, which is 
decremented (note that N = N' + 1 is equivalent to N' = N — 1 A N ^ 0) until 
a state with -i p is reached. For more details on inductive proofs see [Bal04]. 



5 Embedding Statecharts in ITL 

In this section we describe the integration of statecharts into the ITL framework. 
The key idea is to treat a stateclrart SC as a formula, with the idea that I f= 
SC holds if I is a trace of SC. A configuration of a stateclrart is represented 
as a valuation of stateclrart variables variables(SC). The stateclrart variables 
are flexible variables and, therefore, additional primed variables v' exists for 
every v € variables(SC). In addition to the data variables vars(SC ), boolean 
variables for each state states(SC) and each event events(SC) are required, 
describing whether the corresponding state/event is active or not. The input 
variables events env (SC) U vars env (SC), with events env {SC) C events(SC) and 
vars env (SC) C vars(SC), are variables, which the systems environment may 
modify. Local events are eventsi oc (SC) := events(SC) \ events env (SC), local 
variables are varsi oc (SC) := vars(SC) \ vars env (SC). A stateclrart step de- 
scribes a transition from one valuation to another, corresponding to the transi- 
tion relation of the stateclrart. A trace of a stateclrart is a sequence of valuations 
(cjo, o i , . . .) where all relations ct,; p a i+ 1 correspond to the transition relation p 
described by the stateclrart. The semantics of a stateclrart is defined as all such 
sequences of states. 
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Semantics. The statechart semantics depends on the definition of a statechart 
step. Our formalism supports the STATEMATE semantics of stateclrarts [HN96] 
and is based on the operational semantics presented in [DJHP98]. Two important 
extensions are necessary to integrate stateclrarts into our ITL framework. In 
[DJHP98], a statechart step directly computes the successor valuation of the 
statechart, whereas in our setting, a step has to compute the values of the primed 
variables. Then the tl step rule computes the actual transitions to the successor 
valuations. The second extension is the following: [DJHP98] defines the semantics 
of stateclrarts as the set of traces (<jq, • • ., oy t ), where the transition relation of the 
statechart p holds for every step, i.e. ct,; p (Ti+r, and the valuation op is an initial 
valuation (the initial states are active). Traces are required to be maximal, i.e. for 
finite traces: <r n (f dom(p). This is not sufficient for our calculus, since symbolic 
execution leaves the initial state. Therefore, we generalize the definition of the 
statechart semantics to traces with a consistent initial valuation a o- A valuation 
is consistent, if it assigns true to exactly one sub-chart of every or-state. The set 
of all maximal statechart traces is defined as 

traces a(SC) := {(op, . . ., <j„ ) | n € IN)*,, a j p <Ti+i,a n ^ dom(p), a o consistent} 

Note, that the algebra A used in the definition makes it dependent on the un- 
derlying algebraic specification which defines the data part of the statechart. Be- 
cause all initial valuations are consistent, every initial trace is in traces^(SC). 
This definition enables us to prove properties for stateclrarts, which do not start 
in an initial configuration. Such properties are often useful as lemmas. 



Embedding. The semantics of stateclrarts is the set of maximal traces of the 
statechart and the semantical integration into the ITL framework is straightfor- 
ward. 

A, I |= SC :4=> I € traces a(SC) 

In this paper, we will not present the definition of p, because it basically depends 
on the definitions in [DJHP98]. Instead, we show in Sect. 6 how to compute the 
successor valuations in the calculus. A formal definition of p and a correctness 
proof for the calculus is given in [Tlru04] . 



6 Statechart Calculus 



Unwinding a statechart step can be split up into two tasks. First, we have to 
compute all possible steps by Steps(SC, T h A). Second, for each possible step 
stp € Steps (SC. r b A) we have to compute the effects of the active transitions 
and static reactions contained in stp. These actions modify variables and gen- 
erate events. Because transitions leave and enter states, the state configuration 
changes, too. The rule scheme for unwinding stateclrarts is defined as 



V st Pi eSte P s(sc,r h a ) e xec(stpi) , r h 

' ' " sc, r h a 



A 



sc unwind , 



(1) 
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with exec(stp) := cond(stp) A step(stp) A o nxt(stp). Because our approach al- 
lows complex predicates over algebraic specifications as guards, we cannot always 
determine automatically if a guard is satisfied or not. This is in contrast to ap- 
proaches which allow finite data structures only, where a model checker can 
decide such conditions. Therefore, we compute activation conditions cond(stp) 
for a possible statechart step. Only if cond(stp) holds, the step is executed. 
Otherwise, the condition is contradictory to the other preconditions. 

step(stp) executes a single statechart step and nxt(stp) computes the active 
states of the successor valuation. Together, they implement the transition rela- 
tion p, defined by the statechart. The formal definitions of cond(stp), step(stp), 
and nxt(stp) follow in Sect. 6.2. 

6.1 Computing Possible Steps 

A step consists of maximal sets of non-conflicting active transitions. Transitions 
are in conflict, if they leave the same state. We require that the sets of transitions 
are maximal to guarantee, that an active transition is actually executed, unless a 
conflicting transition is executed in this step. Because of concurrent states (and- 
states), a maximal set of non-conflicting active transitions is not necessarily a 
singleton. 

The STATEMATE semantics of statecharts defines a top-down priority for 
conflicting transitions: assume an active or-state s with an active sub-state si 
and two active transitions t with source state s and t\ with source state si. 
Because the execution of t leaves s and all its sub-states (even si), t and t\ are 
in conflict. The priority rule of STATEMATE statecharts solves this conflict in 
favor of t. 

Analogously to [DJHP98], we present a computation of steps, which respects 
all these requirements. Roughly speaking, the algorithm computes the transition 
set in a top-down fashion. For an and-state, all possible steps from the sub- 
states have to be considered. The algorithm computes the Cartesian product of 
the steps from the sub-states. For an or-state, the algorithm computes a set of 
active transitions. If this set is empty, the transitions of the active sub-state are 
considered (the priority rule is respected), otherwise all these transitions are in 
conflict and the result is a set of steps, where every step is a singleton set of one 
active transition (non-conflicting is respected). Finally, a basic-state yields an 
empty step. 

Depending on the current sequent SC, r b A, a state s and an activation 
condition g the function 

steps : Sequent x states(SC) x Fma — > (Fma, p(trans(SC))) 

computes all possible steps stp = (gr,T) with activation condition gr for the 
maximal non-conflicting transitions T. Here, Fma denotes the set of all interval 
temporal logic formulae. Based on this auxiliary function 

Steps{SC,r b A) := steps(r b A, root (S C), true) 
computes all possible statechart steps. steps(r b A,s,g) is defined as 
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1. models) £ {basic, term}: 
steps(r b A,s,g) := {(5, 0)} 

2. mode(s) = and: 

Let {si, . . s n } = childs(s), then 

steps(r b A, s, g) := 

{(31 A ... A g n , UlLi T i ) I (9hTi) £ steps(r b A, s t , s t A g)}, 

3. mode(s) = or: Let 

— S' = {§ | s £ childs(s) and T b A, s is not provable}, 

- T s = {t Sl , . . ., t$ k } = {t | source (t) = s} and 
— T = {<1, . . ., tk} = Uses' 

Every transition in T has the same priority and they are in conflict. 
steps(r b A,s,g) := 

{( gt , £ T and gt := g A guard{t ) A source{t )} U 

(^J steps(r b A, s', g A s' A ~>guard(t s ' i ) A ... A guard (t s ' k )) (2) 

s'eS' 



A basic state cannot execute any transition, so the result is a set of an empty set. 
An and-state executes every transitions of its sub-states in parallel, so we have to 
compute the Cartesian product of the transitions from the sub-states. The main 
difference to the step computation in [DJHP98] is in item 3., where an or-state is 
considered. First, it has to be determined, which states are possible source states 
for active transitions. Since we allow partially specified state configurations, 
active states cannot be determined fully automatic. We approximate the set by 
collecting those states s in S' where r b A, ->s is not provable using the simplifier 
of KIV. The set Tg computes the transitions with source state s and the set T 
contains all possibly active transitions. 

All transitions in T are in conflict (in an or-state, only one transition can be 
executed) and can be executed, if the guard is evaluated to true and its source 
state is actually active. Therefore, the activation condition g t for a transition t is 
gt '■= g A guard (t ) A source{t). The precondition g describes, that no transition 
of a super-state is active. 

If a state s is active, but none of the guards of any transitions t £T s holds, 
transitions from sub-states of s can be executed. We add the condition, that no 
guard of t £ Tj is enabled to the activation condition for the recursive call of 
steps in equation (2) . 




Interactive Verification of Statecharts 



365 



Example 1. Step Computation (I) 

Consider the stateclrart on the left where * marks ac- 
tive states. Let guard (fi) = gi, guard (t 2 ) = 32, and 
guard(t 3) = g 3 be the guards of the transitions. We only 
add active states to the activation condition, if necessary. 



steps(r b A, si, true) = {(ffi, {ti}), 0 )} 

steps(r b A, s 2 , true) = {(g 3 , {f 3 }), (->33 A g 2 , {t 2 }), ( ->33 A ->32, 0 )} 
Steps(SC , E b A) = steps(r b Z\, s,true) = 

{(ffi ^ 537 {t 1 ,^ 3 }), ( _, 3i A 1/3, O 3 }); (51 A ->P3 A g 2 , {ti,t 2 }), 

A -153 A < 72 , {* 2 }), (51 A -153 A - 152 , {*i}), (“'Si A ->33 A ->52,0)} 

Now, let us consider the state s with a generalized state configuration. We ab- 
stract from the active states in Si. If either or Si 2 is active, we get: 

steps(r b A, si, true) = {(51 A si i; {*i}), (->31 A si i; 0 ), (si 2 , 0 )} 
steps(r b A, s 2 , true) = {(g 3 ,{t 3 }),(^g 3 A g 2 ,{t 2 }),(^g 3 A^g 2 ,®)} 

Steps(SC, r b A) = steps(r b A,s, true) = 

{((/I A Si, A <73 , {ti,t 3 }), (“'Si A Sij A g 3 ,{t 3 }), (si 2 A <73 , {t 3 }), (si A s^A 
“■ 93 A g 2 , {ti , t 2 }), (“>3i A Si x A % 3 A g 2 ,{t 2 }), (si 2 A -*g 3 A g 2 , {^ 2 }) , (31 A 
si, A ~>g 3 A ->32, {*i}), (“'Si A Si x A ->g 3 A ->32,0), (si 2 A ^33 A ->32, 0 )} 




Example 2. Step Computation (II) 

Consider the stateclrart SYS of the timer example and assume that the initial 
states Off and Idle are active. If we want to prove Ux < k, we get the sequent 
SYS, On, Idle b Da : < k and the step algorithm computes the following possible 
steps: 

steps ((On, Idle, I 1 Dx < 6), true) := {(press A set, {t±,t 3 }), 

(press A ->set, {fi}), (-^press A set,{t 3 }),(^press A *u sef,0)} 

The presented step computation extends the one, presented in [DJHP98]. We 
added the possibility to compute and return activation conditions for steps. 
This extension is necessary, because we have to consider guards for transitions, 
which cannot be decided automatically. A second extension is the possibility to 
cope with partially specified state configurations. Therefore, we have to add the 
source state of a transition to its activation condition. 

We also consider static reactions and inter level transitions in our approach, 
but omitted these concepts for this presentation. For details we refer to [Thu04]. 



6.2 Step-Execution 

We define the execution of a stateclrart step with sequential programs. The pro- 
grams ‘implement’ the step semantics. We sequentialize the execution of parallel 
transitions according to the semantics from Damm et al. [DJHP98]. We respect 
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the execution of parallel transitions, although we implement the step execution 
with sequential programs. To solve read conflicts, where an action reads a vari- 
able already changed by a parallel action, we copy variables v in a copy v. In the 
following, we assume for every flexible variable v € variables (SC) an additional 
auxiliary variable v and that the actions of transitions assign their values to these 
auxiliary variables. 1 To solve write conflicts, where different actions change the 
value of one variable, we introduce nondeterminism, where every action ‘wins’ 
once (see below). 

We distinguish between micro- and macro-steps. A macro-step is executed, 
if an empty set of enabled transitions is computed. 



step((g,T)) 



T = 0, StePmakroiT ) 

otherwise, step m ikro(T) 



Micro-Step. A micro-step step m ik ro '■ trans(SC) —> Fma is defined as 

stepmikro(T) := V aeper m (T)( c °Py^ reset 1 -, reset e ', exec(a))set. 

As described above, we respect write conflicts through nondeterminism by ex- 
ecuting every possible sequence of actions (a € perm(T), perm computes the 
permutations of the transition set T) . 

To solve read conflicts, we copy variables from v = vars(SC) U events(SC) 
to v with copy. Then, we reset every event with reset 1 , by assigning false to the 
boolean variable, representing an event. To observe generated environment steps 
at the end of a macro-step, we reset them only in the first micro-step after a 
macro-step. Then tick holds. Resetting environment events is done with reset e . 
Now, we can execute the actions. Because we already considered read and write 
conflicts, the execution can be sequential. Finally, set requires, that the primed 
variable (unprimed ones in the next configuration) get the values, computed 
before. The corresponding programs are defined as 

copy := v := v for v = vars(SC) U events(SC), 

reset 1 := e := false, for e = eventsi oc (SC) U {tick}, 
reset e := if tick then e := false for e = events env (SC) , 
exec(a) := ai; . . a n for a = a 1, . . ., a n , and 
set := v = v' for v = vars(SC) U events(SC). 

In addition to the given step computation, STATEMATE stateclrarts generate 
also events when states are entered and exited. We consider these events in our 
calculus, too, but have omitted this detail here (see [Tlru04]). 



Macro-Step. A macro-step step ma k r o ■ trans(SC) —> Fma is defined as 

stepmakro(stp) := ( copy, reset l )set e A set 1 

1 Reading context variables $v from STATEMATE corresponds to reading v, reading 
‘normal’ STATEMATE variables, corresponds to reading v in our setting. 
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Analogous to a micro-step, we copy the variable values and reset the events. 
Then, we label the macro-step with the tick event and require, that the primed 
variables for local events and variables values get the current values. 



set e := tick' = true 

set 1 := v = v' for v = eventsi oc (SC) U varsi oc (SC) 

A macro-step does not restrict the primed variables of environment events. A 
temporal logic step assigns arbitrary values to them to model new input to the 
environment variables. 



State Configuration. In addition to the step computation, we have to com- 
pute the active states for the successor valuation. They depend on the current 
transition set T. Let S := entered(T) U active(T) be the set of active states 
in the next configuration, S := states(SC)\(entered(T) U active(T)) the set of 
inactive states, entered computes the states which will be entered by executing 
the transitions T , active the states, which were neither entered nor exited and 
entered, the states, which were entered through the current step. Then 

nxt(T) := A s A A - -1 s A SC 

v ' ' 'seS ' 'seS 

computes the active states of the next configuration and requires that stateclrart 
formula SC holds again (and can be executed further). 



Example 3. Step Execution 

Let us consider the timer example once again and denote the stateclrart SYS. 
We want to prove the sequent SYS , Off, Idle b Ux < k, which we abbreviate 
to SYS, r |= ip. Then the step computation computes four possible steps and 
therewith four possible premises for the sc unwind rule. 

(1) (press A set) A step((press A set, {t\, fa})) A onxt({t\, £3}), T b p 

(2) (-1 press A set ) A step((~>press A set, {£3})) A onxt({ts}) , r h ip 

(3) ( press A -1 set) A step((press A ~^set, {fi})}) A onxt({t\}) , T b <p 

(4) (-1 press A ~^set) A step((~^press A -> set, 0)) A o nxt(%), r h p 

sys, r b p 

We only consider the cases 3 and 4 in detail. The 3rd case is a micro-step and the 
4tlr case a macro-step. Copying variables and resetting the events is independent 
from the concrete step. 

copy = tick, set, sw-off , x := tick, set, sw-off, x 
reset 1 = tick, set, sw-off := false, false, false 
reset e = if tick then press := false 




368 



A. Thums et al. 



The micro-step has to execute the transition t\ and assign the computed values 
from the step to the primed variables, to describe the valuation of the next step. 

exec(< set >) = set := true 

set = tick, set, sw-off, press, x = tick' , set' , sw-off' , press', x’ 

The whole micro-step results in 

step mikr 0 ((press A ->set, {ti})) = ( copy, reset 1 ; reset e ; exec(< set >))set. 

The macro-step in the 4tlr premise resets every event and generates the tick- 
event. Because we do explicitly not assign any value to primed variables for 
environment variables and events, the following temporal logic step assigns an 
arbitrary value to environment variable press. 

set e = tick' = true 

set 1 = set, sw-off, x = set' , sw-off' , x’ 

We get the following macro-step. 

step m akro{hpress A -.set, 0)) = (copy; reset 1 ) set e A set 1 . 



6.3 Tool Support 

We implemented specification and proof support for statecharts in KIV. The 
specifications are incorporated into the correctness management of the KIV sys- 
tem. If a statechart specification is changed, every lemma based on this specifi- 
cation becomes invalid. 

Because our statechart semantics does not require to specify lemmas for 
statecharts, which start execution in an initial state, we are able to specify and 
prove lemmas for intermediate states. E.g., we can prove something like “if we 
are in state Cnt, we will stay there for k macro-steps, at most”. We can use this 
statement in other proofs as a lemma and apply it, if we reach the state Cnt. 

The proof strategy of symbolic execution leads to diagrammatic proofs. We 
have to unwind the statechart and execute the statechart step. Thereafter, we 
unwind the temporal operator, get a predicate logic proof condition for the cur- 
rent valuation and a temporal logic proof condition for the rest of the trace. If 
we have proven the condition for the current valuation, we turn to the succes- 
sor valuation, where we can unwind the statechart again. This leads to proofs, 
following the execution of the statechart. This means, that we do not trans- 
late a statechart into a flat transition system, but preserve the structure of the 
statechart. 

We automated this sequence of rule application through heuristics in the KIV 
system. We extend the heuristics for ITL verification, to apply the sc unwind 
rule. The resulting heuristics enable us to automate simple statechart proofs. As 
an example, the proof for the property □,t < t of the light control, as shown in 
Fig. 2 of Sect. 2, can be automated except for the generalization step from x = 0 
to x < k. If a concrete k is given, e.g. k = 6 the proof is fully automatic. 
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7 Example: Radio-Based Level Crossing Control 

In this section we will describe the application of the presented calculus on a real 
world case study. This case study is a reference case study of the German research 
councils priority program 1064. we will briefly describe the problem, then present 
how it is modeled in statechart notion and finally give some verification results. 

The German railway organization, Deutsche Bahn, prepares a novel technique 
to control level crossings: the decentralized, radio-based level crossing control 
(FunkFalrrBetrieb, FFB [FFB96]). The main difference between this technology 
and the traditional control of level crossings is, that signals and sensors on the 
route are replaced by radio communication and software computations in the 
train and in the level crossing. 

Instead of detecting an approaching train by a sensor, the train computes the 
position where it has to send a signal to secure the level crossing. Therefore, the 
train has to know the position of the level crossing, the time needed to secure 
the level crossing, and its current speed and position. When the level crossing 
receives the ‘secure’ command it switches on the traffic lights and closes the 
barriers. When they are closed, the level crossing is ‘safe’ for a certain period 
of time. The stop signal, indicating an insecure crossing, is also substituted 
by computation and communication. The train requests the status of the level 
crossing. Depending on the answer the train will brake or pass the crossing. A 
STATEMATE reference model for the radio based crossing control is presented 
in [KT02] and a safety analysis with fault trees in [TO03,RST00]. 



7.1 Specification with Statecharts 

We specified a version of the radio-based crossing control with statecharts in 
KIV. 

Fig. 3 shows the graphical representation of the specification, that focuses 
on the problem of closing the barriers early enough and braking in time, if 
something went wrong (the reference model also considers traffic lights, etc.). 
We also modeled faulty behavior, highlighted by the gray box, but concentrate 
on the functional behavior, at first. 

The whole setting is specified with three parallel statecharts, one chart for 
every system component. The chart train specifies the behavior of the train. 
An approaching train sends a closing request to the crossing, if the predicate 
close(pos,v, abrkJc) holds, pos indicates the current position of the train, v the 
current speed, a^rk the maximal deceleration, and the level crossing Ic. The 
closing request close sn d will be received ( close rcv ) by the crossing if no commu- 
nication error has happened. Then the crossing closes the barriers within tc c i 
time units. Thereafter, the barriers are closed for maximal t max time units or 
until the train passes the crossing. 

The train sends a status request status sn d , which will also be delayed by the 
communication, and awaits an answer within a certain amount of time. If the 
crossing receives the status request status rcv and the barriers are closed (the 
state closed is active), the crossing acknowledges the status request ( ack sn d )■ If 
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Fig. 3. Radio-Based Level Crossing Control 



the train receives ack rcv in time, it will pass the crossing, otherwise the train 
will brake and stop before the level crossing Ic. 

Now, let us consider faulty behavior. We modeled the failure of brakes 
{Err Brake), the break down of the communication channel ( Errcom ), a faulty 
acknowledgment of a status request {Errciose) and an undesired opening of the 
barriers ( Erro pe n )• Every fault is modeled by an indeterministic choice. E.g., 
the failure of the brakes are modeled by an additional transition from the state 
wfs to brake. In contrast to the ‘correct’ transition, this additional one does not 
set the deceleration to abrk, so the train does not brake. The other failures are 
modeled analogously. 



7.2 Algebraic Specification 

The underlying data types for the radio-based crossing control system are alge- 
braically specified using natural numbers. In addition, we specified the predicates 
close{pos, v, abrk, lc) and request{pos, v , ab r k,lc) to compute the optimal time for 
closing the barriers and requesting the status of the crossing. These predicates 
rely on the braking distance braked{v , abrk)- Within each macro-step, the static 
reaction sr \ computes the position and velocity of the train. 

tick /pos := pos + v, if v > a then v := v — a else v := 0 

With the deceleration a > 0 and the initial velocity Vq, the distance until the 
train stops is 

[v 0 /a] 

braked{vo, a) := vq + ( Vo — i * a) 

i—0 



(3) 
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(with the distance vq ™ * Is = vo to). Based on braked, we can define the predi- 
cates dose and request 

close(pos, v, a^rk , lc) := pos > Ic — ( braked(v , a^k) + tc c i * v) and (4) 

request(pos, v, abrk, lc) := pos > lc — braked(v, abrk )• (5) 

7.3 Formal Safety Analysis and Verification 

In the ForMoSA project, we developed the safety analysis technique formal fault 
tree analysis (formal FTA, [STR02]). Formal FTA integrates classical fault tree 
analysis (FTA, [VGRH81]) with formal methods. For the radio-based crossing 
control we analyzed the hazard “collision of the train on crossing”. A detailed 
fault tree is described in [Thu04]. 10 verification conditions are attached to this 
fault tree. Altogether they guarantee that the hazard can happen only if one 
of the causes described by the leaves of the fault tree (e.g. failure of brakes 
Err Brake) happens. Informally, each verification condition is a temproal formula 
that intuitively says: “if some consequence happens, then the cause must have 
happened before or at the same time” (for a formal definition of the conditions, 
see [OTSW04] in this volume). 

All verification conditions could be verified with KIV. The proofs typically 
proceed by induction over the number of steps it takes to reach the consequence 
(if the consequence is never reached on a trace, the condition is trivially true). 

Some conditions are trivial to prove, but most have rather complex proofs 
with several hundred proof steps, so they are too complex to show them in detail. 
Two reasons contribute to the complexity: one is the indeterminism inherent in 
statecharts, the other is a lack of modular proofs: even though most conditions 
give properties of only one component (e.g. the train), all properties must still be 
proved over the full statechart. Research in modular proofs is still an important 
topic for further research. 

As subtasks of the proofs algebraic properties of the definitions (3), (4) and 
(5) have to be shown: thereby it is proved that the requests to close the gates and 
the distance where to brake (when the crossing does not acknowledge closing of 
the gates) are indeed a safe distance away from the crossing, such that the train 
is able to stop in time. 

8 Conclusion and Future Work 

We developed interactive proof support for statecharts with infinite data struc- 
tures. We consider statecharts with finitely many states, but specify data, func- 
tions, and predicates by algebraic specifications. Guard conditions of transitions 
refer to data types using first-order logic. Statechart actions are described by 
sequential programs and proof conditions for statecharts are interval temporal 
logic formulas. 

We support STATEMATE statecharts with their asynchronous macro-step 
semantics. As far as we know, this is the first approach which offers proof sup- 
port for infinite statechart models. We defined a sequent calculus for verifying 
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statechart properties, which is implemented in the KIV system. The calculus has 
been successfully applied on the radio-based level crossing control. 

Up to the present, we considered the verification of statecharts. Damm et al. 
[DJHP98] gave a modular semantics based on activities, where complex systems 
can be decomposed in modular sub-activities. Each activity is controlled by a 
statechart. Modularization is a prerequisite for proving properties for complex 
systems. Future work will be to extend our approach to modular statechart 
verification. 
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Abstract. The language of Message Sequence Charts (MSC) is a well- 
established visual formalism which is typically used to capture scenarios 
in the early stages of system development. But when it comes to rigorous 
requirements capturing, in particular in the context of formal verifica- 
tion, serious deficiencies emerge: MSCs do not provide means to distin- 
guish mandatory and possible behavior, for example to demand that a 
communication is required to finally occur. 

The Live Sequence Chart (LSC) language introduces the distinction be- 
tween mandatory and possible on the level of the whole chart and for the 
elements messages, locations, and conditions. Furthermore they provide 
means to specify the desired activation time by an activation condition 
or by a whole communication sequence, called pre-chart. 

We present the current stage of LSC language and a sketch of its formal 
semantics in terms of Timed Brichi Automata. 



1 Introduction 

Message sequence charts (MSCs) are a well established visual formalism for the 
description of inter-working of processes or objects. There is also a standard for 
the MSC language, which has appeared as a recommendation of the ITU [1]. 
The standard defines the allowed syntactic constructs, and is also accompanied 
by a formal semantics [2] that provides unambiguous meaning to basic MSCs. 
Despite the widespread use of MSCs and the foundational efforts cited above, 
several fundamental issues have been left unaddressed. One of the most basic of 

* This research was supported by the German Research Council (DFG) within the pri- 
ority program Integration of Specification Techniques with Engineering Applications 
under grant DA 206/7. 
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these is, quoting [3]: “ What does an MSC specification mean: does it describe all 
behaviors of a system, or does it describe a set of sample behaviors of a system?" . 

In this paper we will provide an introduction to the Live Sequence Chart 
language, introduced by Damm and Harel in [4], as a conservative extension to 
the standard MSC language. In the first section, we will motivate the need for 
another visual formalism and describe the basic features of the LSC language 
informally. In the second section we will sketch the formal semantics of LSCs in 
terms of timed automata, and furthermore provide an idea of the relation be- 
tween LSCs and a compatible reference system. The underlying complete syntax 
and rigorous semantics of the LSC language can be found in [5] . 



1.1 Shortcomings of Message Sequence Charts 

Typically MSCs are used to capture sample scenarios corresponding to use- 
cases. While the system model becomes refined and conditions characterizing 
use-cases evolve, the intended interpretation often undergoes a metamorphosis 
from an existential to a universal view: earlier one wants to say that a condition 
can become true and that when true the scenario can happen, but later on one 
wants to say that if the condition characterizing the use-case indeed becomes 
true the system must adhere to the scenario described in the chart. 

While the distinction between mandatory and possible behavior is one of 
the most urging deficiencies which needs to be addressed in order to construct 
semantically meaningful computerized tools for describing and analyzing use- 
cases and scenarios, the formal semantics for MSCs as described in [2] leave a 
good deal of questions beyond unanswered: 

Existential or universal view. An MSC shows only one sample run of the 
system, one scenario, i.e. it is not possible to specify a mandatory protocol 
between the communicating entities. 

Safety and Liveness properties. The MSC semantics offers no distinction, 
whether progress is enforced or not, i.e. The semantics in [2] only define 
permitted sequences of events; the occurrence of an event can not be en- 
forced. Using the terms coined by Lamport in [6] MSCs can only express 
safety (nothing bad ever happens), but not liveness properties (something 
good will happen eventually). 

Semantics of Conditions. Conditions in MSCs have no formal semantics. In 
the words of [2]: 11 The semantics of a chart containing conditions is sim- 
ply the semantics of the chart with the conditions deleted from it.” . This is 
obviously not the way to treat conditions from a more formal point of view. 
Simultaneous events. MSCs do not allow more than one event to happen 
exactly at the same time, i.e. there is no notation of simultaneity. 
Activation time. An MSC does not state explicitly when the behavior it de- 
scribes should be observed, i.e. there is no indication of when the MSC should 
be activated during a system run. 
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Time treatment. The treatment of time is only rudimentary, since quantita- 
tive timing is not covered by the semantics, i.e. timer durations are ignored. 
Only the correct sequence of timer events, respectively intervals is enforced. 

The LSC language as described in [5] is a extension to the MSC language 
which addresses these shortcomings and provides a fully worked out formal se- 
mantics. LSCs can therefore accomplish the requirements for the application to 
more advanced use cases like formal verification as discussed in the companion 
paper [7]. 

1.2 Basic LSC Features 

This section presents the key elements of the Live Sequence Chart language. 
The basic idea of LSCs is to allow a distinction between mandatory and pos- 
sible behavior, i.e. most LSC elements can be designated to belong to either 
one category or the other. This distinction is also expressed graphically, which 
contributes largely to the easy understanding of LSC specifications. Mandatory 
elements are depicted by solid lines, possible ones by dashed lines. 

Instances and Messages. Instances and messages are the elementary building 
blocks of LSCs. The graphical representation for instances has been adopted from 
MSCs, i.e. LSC instances consist of an instance head carrying the instance name, 
an instance axis and an instance end, as the example LSC in figure 1 shows. 

As for MSCs, the horizontal dimension 
is the structural dimension and the verti- 
cal dimension corresponds to the time di- 
mension. Deviating from MSCs we depict 
the environment by an instance of its own 
rather than the border of the LSC. When 
using LSCs for formal verification, an ex- 
plicit environment instance offers the pos- 
sibility of expressing assumptions on the 
behavior of the environment within the 
LSC by employing the same elements as 
for the other instances. 

Concerning messages we consider two 
kinds: asynchronous and instantaneous 
ones. Asynchronous messages are visual- 
ized by half stick arrows, instantaneous 

__ . y . , T _ _ , , messages by arrows with solid heads, as 

tig. 1. Kernel LbC features example. . ' 

shown m figure 1. Instantaneous messages 

have to be drawn horizontally to indicate simultaneity of sending and receiving, 
while asynchronous ones are drawn slanted to indicate the passage of time be- 
tween sending and receipt. 

Operation calls, are represented by two instantaneous messages: the method 
call and the return of the method call. For method calls in LSCs we require 



LSC: Features_example 
AC: Act 

AM: Invariant 




Live Sequence Charts 377 



the return message to be stated explicitly, because otherwise confusion arises 
whether messages and other elements following a method call receipt are part of 
the method body. The pairing of operation call and return is indicated graphi- 
cally by widening the instance axis on the receiver side into a thin rectangle which 
marks the operation body; see Sync2 and Ret_Sync2 in figure 1 for example. 



Liveness and Temperatures. One deficiency of MSCs is their inability to 
enforce progress, as mentioned in section 1.1. LSCs overcome this drawback by 
associating a temperature with both locations 1 and messages. The temperature 
can be either hot or cold, the former indicating that progress is enforced. The 
analogy here is that one cannot remain at a hot location for an infinite amount 
of time, because then one would burn ones feet. This obviously requires that a 
hot location has to be left, i.e. the following location has to be reached. At a 
cold location one can stay forever without harming ones feet, i.e. the following 
location need not be reached. In terms of messages this means that a hot message 
has to be delivered, whereas a cold message may be lost along the way. Progress 
information is thus expressed by the temperatures of the messages and along the 
instance lines. 

Graphically hot temperatures are represented by solid lines, cold ones by 
dashed lines. This means that e.g. a hot location is depicted by a solid instance 
axis segment, which starts at this location and ends either at the next cold 
location or the instance end. In figure 1 for example the location of the sending 
of message Sync2 is cold and the next location (the receipt of the return message) 
is hot, so that the instance axis segment in between them is dashed. 



Conditions and Local Invariants. In order to make statements about the 
state of the system boolean conditions referring to attributes or data items of the 
involved entities are used. Graphically, conditions are represented as in MSCs by 
an elongated hexagon (cf. figure 1). Conditions also come in two variants: manda- 
tory and possible. A mandatory condition must be satisfied, i.e. the boolean ex- 
pression associated with it has to hold; violation of the condition is considered an 
error. Possible conditions do not generate an error when they are not satisfied, 
but merely constitute an exit from the enclosing LSC. Mandatory conditions are 
denoted by solid lines (e.g. Condi in figure 1) and possible ones by dashed lines. 

Conditions constrain attributes or data items of entities at one point in time, 
but often it is desired to express validity of a condition over a period of time. 
This observation motivates the introduction of a fitting feature: local invariants, 
which come in two flavors: possible and mandatory, with the same interpretation 
as for conditions. Since local invariants cover a period of time, they need reference 
points for start and end and should thus always be bound to observable events. 
Graphically, local invariants are depicted by a condition symbol, which is rotated 

1 Locations are those points on an instance axis, where some event is attached, e.g. 
sending or receipt of a message, conditions, etc. In section 2.2 we give a formal 
definition of a location. 
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by 90°. A pointed end of the invariant symbol indicates the exclusion of the 
corresponding reference point while a planar end denotes the inclusion (e.g. in 
figure 1 the local invariant Invl includes message Sync2 but excludes message 
Ret_Sync3). 



Simultaneous Regions and Coregions. We now have assembled all basic el- 
ements of our kernel LSC language. The default ordering of these basic elements 
is one after the other from top to bottom along the instance axis. Ordering be- 
tween instances is induced only by messages and conditions ranging over more 
than one instance. Simultaneous regions allow to group several elements, which 
should be observed at the same time. This is essential for determining reference 
points for conditions, local invariants and timers. Graphically they are repre- 
sented by enlarging the location in question into a small filled circle; see figure 1 
for examples. 

A coregion is used to indicate that no ordering is imposed on the events it 
contains, i.e. they may occur in any order. This corresponds to the classical MSC 
view of a coregion with the exception that - as a consequence of the simultaneous 
region construct - we also allow events in a coregion to take place simultaneously. 

Coregions are represented graphically by a dotted line running in parallel to 
the instance axis. This differs from the representation in MSCs, where they are 
depicted as dashed portions of the instance axis. 



Activation, Quantification, and Pre-charts. In the preceding paragraphs 
the graphical elements describing the communication behavior of several inter- 
acting entities are presented. This paragraph adds information about when this 
behavior should be observed and whether it specifies a sample behavior or a pro- 
tocol to be obeyed, therefore addressing the primary criticism outlined before. 

The quantification information represents the distinction between mandatory 
and possible behavior on the chart level. The sample-run or scenario view of 
MSCs, i.e. the interpretation that there exists a run, which fulfills the LSC, is 
covered by the possible mode, which we call existential. The mandatory mode, 
which is missing in MSCs as laid out in section 1.1, expresses that the behavior 
specified in the LSC must be fulfilled by all runs, for which reason it is called 
the universal view. Graphically, the quantification information is depicted by 
the border style of the LSC: a solid border indicates a universal chart, a dashed 
border an existential one. 

For universal LSCs it is vital to be able to characterize the activation point. 
If every run has to fulfill the universal LSC, it must be possible to state at which 
point(s) of the run the LSC should be considered, otherwise the behavior of the 
entire system has to be specified in one LSC, which is clearly undesirable. The 
activation point of an LSC is characterized by two complementary concepts: 
activation condition and activation mode. The activation condition is a boolean 
condition, which expresses the activation point for a chart. The activation mode 
specifies, how often an LSC should be activated; the offered modes are initial, 
invariant and iterative. The initial mode indicates that the LSC is activated 
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at system start only, i.e. it is intended to describe a start-up or initialization 
sequence. The other two modes indicate that the LSC is activated whenever the 
activation condition holds. The difference between an invariant and an iterative 
LSC is that the invariant mode allows a reactivation of the LSC while another 
incarnation of the same chart is still active, while the iterative mode allows only 
one incarnation of the chart at a time. 

It turns out that activation condition and mode do not always sufficiently 
characterize the activation point of a property specification. Often it is necessary 
to know more about the history of a run, before being able to decide, whether the 
LSC should be activated. There may be e.g. more than one way for a run to arrive 
at a certain system state (characterized by a condition) , but the LSC should only 
be activated, if the run has followed a specific “route”. We are for instance only 
interested in activating an LSC, when no errors have occurred so far. This moti- 
vates the introduction of pre-charts which allow to specify a prefix of a run acting 
as a trigger for the actual LSC. Pre-charts allow to specify a prefix or history, 
which must be fulfilled by a run in order to activate the LSC. A pre-chart is essen- 
tially an LSC, i.e. all language constructs can be used in a pre-chart, but its se- 
mantics is different, since the message sequence of the pre-chart is not required to 
hold in the system, but rather must be observed before activating the actual LSC. 
Pre-charts do not replace the activation condition, but extend it; the activation 
condition in the presence of a pre-chart indicates the starting point of the prefix. 
The informal semantics of an LSC with 
pre-chart is consequently: If the activation 
condition holds and afterwards the pre- 
chart is completed, then the LSC is acti- 
vated. 



Time. LSCs allow the specification of 
time constraints either in form of an MSC- 
style timer or in interval notation, with a 
lower and an upper bound. The graphical 
representation of timers is identical to the 
one given in MSC-96, i.e. the setting of a 
timer is represented by an hour glass sym- 
bol, which is annotated by a name and a 
duration and is connected to the instance 
axis by a simple line; a timeout symbol is 
represented by an hour glass symbol, which is connected to the instance axis by 
an arrow; a timer reset is represented by a x-symbol, which is connected to the 
instance axis by a simple line; see figure 2 for examples. 

Timing intervals express quantitative local liveness properties, since they 
refer to neighboring atoms 2 . They are used to give both a minimum and a 

2 Atoms are the most basic building blocks of an LSC, e.g. instance heads, instance 
ends, sending a message or receiving a message. In section 2.2 we give a formal 
definition of an atom. 
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Fig. 2. Examples of LSC timing con- 
straints. 
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maximum delay between two directly consecutive atoms. The delimiting atoms 
can either be located on the same instance axis, or be the sending and receipt 
of an asynchronous message. The intervals are placed next to the instance axis 
between the two locations which delimit them or are attached to the identifier 
of the constrained asynchronous message (cf. msg2 in figure 2) . 



2 Semantics of the LSC Language 

The semantics for the behavior of an LSC is defined in terms of a symbolic timed 
Biiclri automaton in [5]. The procedure of deriving an automaton from an LSC, 
which is called unwinding , is inspired by the semantics definition for Symbolic 
Timing Diagrams presented in [8], which has been taken as a blue print for the 
first version of the LSC semantics in [4] . 

Before describing the the unwinding procedure we introduce timed Biichi 
automata and define the formal syntax of LSC elements, which is the starting 
point for the translation from an LSC into a timed symbolic automaton. 



2.1 Automata-Theoretic Foundation 

The base for the definition of the formal semantics of LSCs is a variation of 
timed Biichi automata. We chose Biichi automata for several reasons: First, 
we use LSCs to describe the communication behavior of reactive systems, i.e. 
systems which must be able to accept and react to input signals at any time. 
These systems are typically designed to operate forever, at least theoretically, 
which means that runs of reactive systems are infinite. Therefore classical finite 
automata are not sufficient for our purpose. Biichi automata ([9]) are one possible 
solution as they accept infinite words. The second reason for choosing Biichi 
automata over other variants of automata on infinite words is that there is a close 
relationship between Biichi automata and linear time temporal logic (LTL) [9, 
10]. Since the main application field for LSCs is property specification for formal 
verification, this is a major advantage. The third reason is that Biichi automata 
allow to express liveness properties easily via their acceptance criterion. 



Timed Biichi Automata. The acceptance criterion for Biichi automata (and 
other automata on infinite words) needs to take the infiniteness of the words 
into account. Informally an infinite word is accepted by a Biichi automaton if its 
run passes infinitely often through (at least) one of the accepting states of the 
automaton; these states are also called fair states. 

When the occurrence times of the letters of words are important, timed lan- 
guages are used and consequently a corresponding type of automaton is needed: 
a timed Biichi automaton. For the definition of timed Biichi automata we loosely 
follow the lead of [11] here, inasmuch as we associate an occurrence time to each 
symbol of a word, yielding timed words. In contrast to [11], however, we only 
consider discrete time instead of dense time. Time is represented by a sequence 
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of time values from the set of non-negative natural numbers: t , € N, which has 
to satisfy two constraints: time is non-decreasing and time always progresses: 

Definition 1 (Timed Word). A time sequence r = tqt±T 2 ■ ■ ■ is an infinite 
sequence of time values Ti £ N for which the following holds: 

1 . Ti < Tj+i,Vi > 0 (t is monotonically increasing) 

2 . \/t € N 3 i > 1 : Ti > t (time always progresses) 

A timed word over an alphabet £ is then a pair (a, t ), where a = (To 17 ! • ■ • is 
an infinite word and r = tqT\ ... is a time sequence. The time value Tj denotes 
the occurrence time of input symbol cq. 

In the untimed case the behavior of the automaton only depends on the input 
symbols, i.e. being in some state the next states of an automaton are determined 
by the current input symbol. In order for an automaton to also accept timed 
words it needs a means to count time, since the choice of the next states also 
depends on the occurrence time of the input symbols in question. This is realized 
by clocks , which can be set to zero on any transition of the automaton and count 
the time since their last reset. This allows for the introduction of clock constraints 
on transitions - i.e. a transition may only be taken, if all its clock constraints 
are satisfied - forcing the input word to obey certain timing requirements. Thus 
time is introduced into an automaton by adding a (finite) set of clocks and 
augmenting transitions by clock resets and clock constraints formulated over 
this set of clocks. 

In the following the definition of a timed Biichi automaton, the set of clocks 
used in the clock constraints of the automaton is added and the transitions 
between states are augmented by clock resets and constraints. The acceptance 
criterion is adjusted accordingly, so that fair states are defined in terms of timed 
words. 

Definition 2 (Timed Biichi Automaton). A timed Biichi automaton TBA 
is a tuple 



TBA := (£, Q, qo,C, — >,F), where 

— £ is a finite alphabet of input symbols, 

— Q is a finite set of states, 

— <70 £ Q is the initial state, 

— C is a finite set of clocks 

— — >C Q x £ x T(C) x T>{C) x Q is the transition relation. A transition 
(q, a, p, 7, q') £ — > represents the change from state q to state q' on input 
symbol a. The set p £ V(C) indicates which clocks are reset when taking the 
transition, the set d>(C) is the set of clock constraints over C and 7 £ d>(C) 
is a clock constraint over C, which has to be fulfilled. 

— F C Q is the set of fair (accepting) states. 
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i?., x < A 



a 



Fig. 3. Example timed Biichi automaton. 



Let (a , t) = (uo, T'o)(cri, ri) ... be a timed word over S. A timed run tr of a 
timed Biichi automaton TBA over timed word (a , r) is an infinite sequence of 
configurations qi,u.i, where qi € Q is the i-th state of the automaton along the 
run and Ui € I is the clock interpretation in this state: 

tr : (g 0 , ^o) (<7i, ^ 1 ) (<72, v 2 ) , with 

To T i T2 

— \/x G C : vq(x) = 0, (initially all clocks are zero) 

- Vi > 0 3 pi, Ji,qi+i) G — >•: [ 7 ij(i'i) = true AV x G pi : v i+1 (x) = 
0 A Mx fL pi'. v i+ i(x) = Ui( x) + n - Ti - 1 

(the target state of each transition is the source state of the following tran- 
sition, the transition respects all its clock constraints, resets all appropriate 
clocks and all clocks, which are not reset, correctly advance the time). 

Let inf(tr) C Q denote the set of states of TBA which are visited infinitely 
often by timed run tr, i.e. infftr) consists of those states q G Q such that q = qi 
for infinitely many i > 0. The language accepted by TBA is defined as the set 
of timed words, for which there is an accepting run of TBA: 

C(TBA) := {{a, t ) | 3 tr = (q 0 , v 0 ) (g 1; vi) : inf(tr) nE/0} 

TO Ti 



Example 1. Figure 3 shows an example of a timed Biichi automaton, which 
accepts the language {(ct, t) | a G a + (ba*c) w A Vi 3j > i : di = b =7 07 = c A Tj < 
n + 4}. 



Symbolic Timed Automata. The timed Biichi automata described so far 
operate on single input symbols only, since they allow but one element of S 
per transition. In order to be able to describe the communication behavior of a 
system, it is necessary to allow more than one observation at a time. 

Symbolic Timing Diagrams (STDs) faced a similar problem, which in [ 8 ] is 
solved by the extension of Biichi automata to symbolic automata, where a run 
is extended to a computation sequence referring to valuations of system vari- 
ables and formulas are allowed as transition annotations in the automaton. We 
adopt this strategy for the LSC semantics definition and therefore use symbolic 
automata. 

In [ 8 ] Schlor does not consider quantitative timing for STDs, so that sym- 
bolic automata are untimed. We consequently extend the definition of symbolic 
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automata to also encompass (discrete) time, similar to timed Biichi automata. 
First, we extend the notion of a timed word to a timed symbolic word (called a 
computation sequence in [8]). 

Definition 3 (Timed Symbolic Word). 

Let AP be the set of atomic propositions. A symbolic word is an infinite sequence 
9 = 00^1^2 • • • , where 9 i : AP — > B is a valuation, which assigns to each 
v £ AP a boolean value. Let r be a time sequence. A timed symbolic word then 
is a pair ( 9 , t) = ($o, tq)(9i, ri)(f?2, T2) . . . , where Ti denotes the occurrence time 
of valuation 9 i . 

In order to refer to the occurrence of several communication events it is 
necessary to extend the timed Biichi automata to allow formulas: 

Definition 4 (Formula over AP). Let AP be a set of atomic propositions. A 
formula if over AP is a boolean expression produced by the following rides: 

psi := <7 | if | -iif | if\ A tp2 | V’l V ip2 1 with a £ AP. 

The set of all formulas over AP is denoted by BExprAP- 

We can now define in extension of definition 2 on page 381 a timed symbolic 
automaton: 

Definition 5 ((Non-deterministic) Timed Symbolic Automaton). 

A timed symbolic automaton TSA is a tuple 

T SA := ( AP,Q,qo,C , — >,F), where 

— AP is a finite alphabet of input symbols (atomic propositions), 

— Q is a finite set of states, 

— <70 £ Q is the initial state, 

— C is a finite set of clocks 

— — >C Q x BExprAP x V(C) x <P(C) x Q is the transition relation. A transi- 
tion (q, if, p, 7, q') £ — > represents the change from state q to state q' while 
satisfying formida if. The set p £ V(C ) indicates which clocks are reset when 
taking the transition, the set <L(C) is the set of clock constraints over C and 
7 £ d>(C) is a clock constraint over C, which has to be fidfilled. 

— F C Q is the set of fair states. 

A timed run tsr of a timed symbolic automaton TSA over a timed symbolic 
word (i 9 ,t ) is an infinite sequence of configurations ( qi,Pi ), where qi £ Q is the 
i-th state of the automaton along the run, Ui £ / is the clock interpretation in 
this state: 



tsr : ( q 0 , ^0) fe, ^2) 

T 0 T X T 2 



. . , with 



Vx £ C : pq(x) = 0, (initially all clocks are zero) 
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- Vi > 03(q i ,ip i ,p i ,'y i ,qi +1 ) G — K 9i | = ^ A [7*]( vf) = true A Vx G Pi : 
Vi+i(x) = 0 A \/x £ pi : v i+ i(x) = Vi{x) + n- n - 1 

(t/ie target state of each transition is the source state of the following tran- 
sition, the boolean expression annotating the transition is evaluated to true, 
the transition respects all its clock constraints, resets all appropriate clocks 
and all clocks, which are not reset, correctly advance the time). 

Let inf (tsr ) C Q denote the set of states ofTSA which are visited infinitely 
often by timed run tsr, i.e. inf (tsr) consists of those states q G Q such that 
q = qi for infinitely many i > 0. The language accepted by TSA is defined as: 

C(TSA) := {(0, t) |3 tsr = q 0 -% <71 q 2 : inf (tsr) D F/ 0} 

Tq T 1 T2 



2.2 LSC Syntax 

In order to introduce the unwinding procedure we define the formal syntax of 
LSC elements, which is the starting point for the translation from an LSC into 
a timed symbolic automaton. 

An LSC consists of several components: the body of the LSC - i.e. the in- 
stances and events defined on it — , the activation condition and mode, the quan- 
tification and the pre-chart While the complete LSC Syntax is defined in [5], the 
focus in the remainder of this section is on the body of the LSC. 

Definition 6 (LSC). An LSC is a tuple 

L = (l, ac,pch, amode, quant) 

with ‘l’ the body of the LSC, ‘ac’ the activation condition, ‘ pch' the pre-chart, 
amode G {initial, invariant, iterative} the activation mode and quanta {existen- 
tial, universal } the quantification. 

An LSC body consists of a number of instances, which are collected in the 
set Inst(l). In the following let l denote the body of an LSC L, and let i G 
Inst(l) denote some instance of l. The basic blocks (atoms) of which an LSC 
body is comprised are the following: instance heads, instance ends, sending a 
message, receiving a message, condition atom (local to one instance), start of a 
local invariant and end of a local invariant. 

The atoms carry the progress information of each instance (cf. section 2.3) 
and are organized according to their positioning on the instance axes. The atoms 
are thus instance-wise collected in sets: 

M sgsnd(i), Msgrcv(i) : sets of message send/receive atoms 
Conds(i) : set of condition atoms 3 
LI_starts(i),LI_ends(i) : sets of start /end atoms of local invariants 

There is only one instance head atom, denoted by _Lj, and one instance end 
atom, denoted by Tj, for each instance i, so that it is not necessary to have 




